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Preface 


This  thesis  continues  the  work  of  implementing  the  expert  system  for  the  Ada  version  of 
SAtool-II  ,  which  is  based  on  the  essential  data  model  of  the  IDEFq  language  (16).  IDEFq  is  a 
graphic  approach  to  system  description  developed  by  SofTech,  Inc.  for  the  U.S.  Air  Force  Program 
for  Integrated  Computer-Aided  Manufacturing  (ICAM)  and  is  a  subset  of  the  Structured  Analysis 
(SA)  language  (24)  (20).  The  research  goal  is  to  develop  an  object  based  Ada  CASE  tool  (SAtool 
II)  using  the  abstract  data  model  as  the  requirements  document  (16)  (28). 

The  essential  subsystem  has  been  developed  for  future  integration  with  the  Ada  based,  IDEFq 
CASE  tool,  SAtool  II,  (28).  The  original  SAtool  was  developed  by  Steve  Johnson  (13).  D.  H.  Jung’s 
explored  the  idea  of  performing  syntax  checking  on  the  SAtool  output(14).  His  research  focused 
on  the  prototype  development  of  an  IDEFq  syntax  (language)  validation  tool  which  is  an  expert 
system  to  perform  a  syntax  validation  of  the  IDEFq  diagram.  Intaek  Kim  continued  research  on  the 
integration  of  an  expert  system  with  SAtool(15).  Overlaping  with  the  work  of  Kim,  Terry  Kitchen 
and  Jay  Tevis  jointly  designed  the  essential  model  and  graphics  editor  model  for  the  Ada  based 
SAtool. 

The  development  of  this  subsystem,  as  well  as  SAtool  II,  is  part  of  ongoing  research  at  the 
Air  Force  Institute  of  Technology,  in  association  with  the  Strategic  Defense  Initiative  Organization 
(SDIO),  on  the  use  of  IDEFq  as  a  software  requirements  modeling  methodology.  SAtool  II  has 
shown  that  an  Ada  based  expert  system  to  check  the  syntax  of  an  IDEFq  diagram  is  feasible. 
In  this  thesis,  we  discuss  the  design,  development,  implementation,  validation  and  results  of  the 
continuing  research  on  the  expert  system.  This  research  is  performed  to  determine  the  feasibility 
of  Ada  in  the  development  of  CASE  tools  and  expert  systems  and  to  provide  a  subsystem  that  will 
be  integrated  with  SAtool  II. 
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AN  ADA  BASED  EXPERT  SYSTEM 


FOR 

THE  ADA  VERSION  OF  SAtooI  II 


/.  INTRODUCTION 


Background 

To  improve  the  productivity  of  quality  software  has  been  an  objective  ever  since  the  first 
programmer  Ada  Lovelace  first  put  quill  pen  to  paper  to  program  Babbage’s  analytic  engine. 
Software  development  tools  was  expected  by  the  software  developers  ever  since.  The  recognition 
of  the  existence  of  the  Software  Crisis  was  initially  revealed  in  the  International  Conference  of 
Software  Engineering  at  Garmisch,  West  Germany,  in  1968  and  continues  today  (4:1-3).  In  a 
sense,  the  essence  of  the  software  crisis  is  simply  that  it  is  much  more  difficult  to  build  software 
systems  than  our  intuition  reflects  (11). 

In  the  systematic  development  and  analysis  of  specific  algorithms,  especially  for  software 
development,  computational  complexity,  is  a  field  of  study  that  runs  in  parallel  with  algorithmics. 
To  consider  globally  the  class  of  all  algorithms  that  are  able  to  solve  a  given  problem  is  no  doubt 
impossible  in  practice.  Using  algorithmics,  we  may  prove  by  giving  an  explicit  algorithm,  that 
a  certain  problem  can  be  solved  in  an  acceptable  time.  Using  complexity  constraints,  we  try  to 
find  any  algorithm  that  is  capable  of  solving  our  problem  correctly  on  all  instances.  Thus,  it  is 
manageable,  applicable,  and  can  be  implemented.  We  may  have  found  the  most  efficient  algorithm 
possible.  In  this  case  we  say  that  the  complexity  of  the  problem  is  known  exactly;  unfortunately, 
this  does  not  happen  often.  An  algorithm  developer  should  seek  the  design  that  is  consistent  and 
within  the  complexity  constraints  of  the  particular  effort  (6:292). 
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TYaditional  computing  technology  has  been  able  to  develop  powerful  solutions  for  problems 
which  can  be  clearly  and  completely  codified-iiiB,t  is,  problems  that  have  algorithmic  or  closed  form 
solutions.  In  practical  problem  solving  there  are  many  areas  where  such  methods  cannot  be  applied, 
where  experts  are  needed  to  gather  and  interpret  data  and  select  a  strategy  for  solving  a  problem. 
Such  problems  are  typically  poorly  specified,  difficult  to  define,  heavily  dependent  upon  rules  of 
thumb-or  heuristics.  It  is  in  these  less  well  specified  domains  that  expert  systems  can  contribute 
(12:1-1). 

As  a  rule  of  thumb,  software  development  tools  are  crucial  to  the  success  of  such  an  effort 
(19).  Software  development  tools  are  designed  to  save  both  the  time  and  effort  of  the  designers. 
Here  at  AFIT,  we  have  a  tool  called  SAtool(15)  that  could  be  used  as  an  requirement  analysis  tool 
during  the  first  phase  of  the  software  development  lifecycle,  the  requirement  analysis  phase.  Tools 
should  have  a  friendly  interactive  user  interface,  thus  easy  to  learn  and  quick  in  application.  Also 
they  should  produce  acceptable  results. 

In  order  to  develop  a  more  powerful  environment  an  expert  system  funct.on  is  appropriate 
as  a  feature  of  SAtool(16).  Once  it  is  accomplished,  the  usero  can  development  their  require¬ 
ments/specification  using  the  software  development  requirement  analysis  tool.  In  particular  they 
could  perform  syntax  checking  functions  without  time  nsuming  manual  checks.  Some  terms  must 
be  defined  in  order  to  facilitate  the  understanding  of  the  development  of  such  an  expert  system. 

Computer  Aided  Software  Engineering  (CASE).  In  the  process  of  developing  computer 
software,  a  case  tool  is  any  software  tool  used  by  lesigner  during  the  development  of  software.  It 
involves  all  the  tools  that  could  be  integrated  together  as  a  software  working  environment.  CASE 
tools  may  be  used  during  any  of  the  development  phases: 

1.  System  Requirements 

2.  Software  Requirements 

3.  Analysis 
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4.  Program  Design 


5.  Coding  (implementation) 

6.  Testing 

7.  Operations  (11:250) 

Prior  to  the  late  1970s,  the  most  common  method  for  representing  user  requirements  for 
system  development  was  informal  narrative  English  (30:123).  These  requirements  exhibited  sev¬ 
eral  undesirable  characteristics  (30:123-124):  monolithic,  redundant,  ambiguous,  and  maintenance 
difficulties.  The  importance  of  well  defined  software  requirements  is  crucial  to  the  success  of  the 
particular  project  both  in  time  and  efficiency.  Five  important  reasons  are: 

1.  The  later  in  the  development  life  cycle  that  a  software  error  is  detected,  the  more  expensive 
it  will  be  to  correct.  More  time  will  be  wasted. 

2.  Many  errors  remain  latent  and  are  not  detected  until  well  after  the  stage  at  which  they  are 
made. 

3.  Many  requirements  errors  are  made. 

4.  Errors  made  in  requirements  specifications  are  typically  incorrect  facts,  omissions,  inconsis¬ 
tencies,  and  ambiguities. 

5.  Requirements  errors  can  be  detected(9:23~26). 

The  recognized  need  for  an  improved  methodology  led  to  the  gradual  transformation  of  in¬ 
formal  methods  into  semi-formal  methods  that  were  graphic,  partitioned,  and  minimally  redun¬ 
dant  (30:124-125).  Early  formalized  methods  included  Data  Flow  Diagrams  (DFDs),  Entity- 
Relationship  (E-R)  Diagrams,  DeMarco  Data  Structure  Diagrams,  Jackson  Data  Structure  Dia¬ 
grams,  and  Structured  Analysis  (SA)  (24)  (30:299-300).  However,  without  automated  tools  to 
draw  and  validate  the  graphical  models,  the  process  of  developing  and  maintaining  the  models 


3 


sometimes  became  overwhelming,  especially  for  systems  whose  reuuirements  constantly  changed 
and  were  of  considerable  complexity.  Naturally,  this  spurred  research  and  development  of  a  class  of 
products  known  as  Computer  Aided  Software  Engineering  (CASE)  tools  which  support  the  drawing 
and  validation  process(30:128,464). 

Structured  Analysis  (SA)  and  SADT.  A  similar  yet  alternative  graphical  modeling 
method  to  the  DFD  is  SA  developed  by  Ross  (24)  (30:299).  According  to  Ross,  the  SA  technique 
produces: 

a  hierarchically  organized  structure  of  separate  diagrams,  each  of  which  exposes  only  a 
limited  part  of  the  subject  to  view,  so  that  even  very  complex  subjects  can  be  under¬ 
stood.  The  structured  collection  of  diagrams  is  called  a  SA  Model  (24:17) 

SA  permits  requirements  to  be  modeled  in  one  of  two  ways:  data  decomposition  or  activity  (process) 
decomposition  (24:19).  SA  is  the  basis  for  the  development  of  the  Structured  Analysis  Design 
Technique  (SADT^)  by  SofTech,  Inc.  SADT  is  described  in  the  book  SADT:  Structured  Analysis 
and  Design  Technique  by  Marca  and  McGowan.  SADT  is  a  graphical  system  for  systems  analysis 
and  design.  The  SADT  syntax  is  based  upon  an  hierarchical  set  of  diagrams.  A  diagram  at  one 
level  is  decomposed  into  several  diagrams  at  a  lower  level  to  expose  more  detail  as  a  program  is 
developed  (19). 

IDEFq.  IDEFo  is  a  requirements  modeling  technique  developed  by  SofTech  for  the  U.S.  Air 
Force  program  for  Integrated  Computer-Aided  Manufacturing  (ICAM)  (20).  In  fact,  IDEFq  stands 
for  ICAM  Definition  Method  Zero.  IDEFq  defines  a  subset  of  SA  that  omits  the  data  decomposi¬ 
tion  and  only  permits  requirements  to  be  functionally  or  process  modeled.  The  original  purpo.se  of 
IDEFq  is  the  “representation  of  the  functions  of  a  manufacturing  system  or  environment’*.  How¬ 
ever,  IDEFq  can  also  be  used  as  a  graphical  language  for  modeling  system  requirements,  including 
software  systems.  Functions(activities)  are  the  basic  objects  of  decomposition  in  SADT /IDEFq. 

*SADT  is  a  registered  trademark  of  SofTech,  Inc. 
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These  functions  represent  different  processes  which  may  occur  in  a  program.  Tne  graphical  repre¬ 
sentation  for  a  function  is  a  “rectangular  box” .  Data  items  needed  by  or  produced  by  the  different 
processes  are  graphically  represented  as  “arrows” .  These  arrows  are  grouped  into  four  basic  cate¬ 
gories  which  help  defining  the  interface  between  the  different  functions:  inputs,  outputs,  controls, 
and  mechanisms.  More  detailed  explanations  are  illustrated  below: 

♦  function  -  A  function  represents  a  process  or  action,  and  is  best  identified  by  a  name  that 
starts  with  a  verb.  The  function  is  viewed  as  transforming  its  inputs  into  outputs  under  the 
guidance  of  its  controls. 

♦  data  item  -  Data  or  information  produced  by  or  needed  by  a  function. 

♦  input  -  An  data  item  arrow  enter  the  left  side  of  the  function  box 

♦  output  -  An  data  item  arrow  leave  the  right  side  of  the  box. 

♦  control  -  Defines  the  condition  or  circumstances  under  which  the  transformation  from  input 
to  output  occurs. 

♦  mechanism  -  An  arrow  entering  the  bottom  of  the  function,  indicate  a  means  of  performing 
the  functions. 

♦  call  -  A  mechanism  arrow  exiting  from  the  bottom  of  the  box,  indicates  that  the  function  is  a 
shared  model.  That  is,  it  is  decomposed  either  elsewhere  in  the  system  model,  or  in  another 
systems  model. (20) 

An  example  of  an  IDEFq  diagram  is  shown  in  Fig  1,  in  which  each  field  of  Author,  Project,  Date, 
Rev,  Node,  and  Title  must  be  filled.  Each  activity  must  be  named  and  numbered  and  must  have 
at  least  one  control  (arrow  entering  the  top)  and  one  onlput  (arrow  leaving  the  right  .side  of  a  box) 
Each  data  arrow  must  also  be  labeled.  The  function  is  viewed  as  a  transforming  its  inputs  (arrow 
entering  the  left  side  of  a  box)  into  outputs  under  the  guidance  of  its  controls.  Each  function  in 


Figure  1.  F/Xample  of  a  IDEFq  Diagram 

this  diagram  can  be  a  parent  diagram  in  the  decomposition  of  its  child  diagrams.  More  examples 
and  IDEFo  syntax  will  be  introduced  in  chapter  2. 

Data  Dictionary*  The  phrase  data  dictionary  is  almost  self-defining.  The  data  dictionary 
is  an  organized  listing  of  all  the  data  elements  that  are  pertinent  to  the  system,  with  precise, 
rigorous  definitions  so  that  both  user  and  systems  analyst  will  have  a  common  understanding  of  all 
inputs,  outputs,  components  of  stores,  and  intermediate  calculations  (30.189).  A  data  dictionary 
is  a  technique  that  usually  accompanies  one  of  the  graphical  modeling  techniques  (27:82-83). 
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SAtool.  SAtool  is  a  C-based  CASE  tool  for  assisting  the  software  engineer  in  the  require¬ 
ments  phase  of  the  software  development  life  cycle  (13:6-1).  SAtool’s  graphical  language  is  based 
on  IDEFo  which,  in  turn,  is  based  on  the  SADT.  SAtool  allows  the  user  to  perform  requirements 
analysis  by  developing  IDEFo  diagrams  and  associated  data  dictionaries. 

SAtool-II.  The  essential  model  and  graphics  editor  model  are  being  develop  as  an  object 
based  Ada  CASE  tool  (SAtool  II)  using  the  abstract  data  model  as  the  requirements  document 
(16)(28).  The  development  and  implementation  of  an  object  oriented  design  (OOD)  in  Adu  for  the 
essential  data  model  is  achieved.  SAtool-II  differs  from  its  predecessor  SAtool,  in  that  SAtool-II  is 
to  be  fully  implemented  in  Ada  programming  language  and  more  functions,  like  a  syntax  checking 
expert  system  are  expected  to  be  completed  in  Ada  as  well. 

SAtool-II  is  designed  for  individuals  who  are  familiar  with  structured  analysis  and  SADT.  In 
order  for  SAtool-II,  or  any  interactive  analysis  too),  to  be  effective,  it  must  be  able  to  capture  the 
data  information  entered  by  the  user  and  stored  it  into  some  type  of  database.  Thus  all  the  input 
information  will  be  examined  by  the  tool  system,  prompt  the  user  when  ambiguities  happen  and 
create  a  complete  data  dictionary  without  further  manual  inputs.  SAtool-II  stores  data  derived 
from  the  SADT  diagrams  in  a  standard  file  format  which  can  be  read  by  the  common  database 
interface.  The  purpose  of  this  stored  standard  file  is  for  the  future  compatibility  with  as  many 
database  tools  in  existence  as  possible  (17). 

Exp'^^rt  System.  The  first  step  in  .solving  any  problem  is  defining  the  problem  area  or 
problem  domain.  This  consideration  is  just  as  true  in  artificial  intelligence  (AI)  as  in  conventional 
problem  solving.  According  to  Luger,  the  attempted  definition  of  AI  is: 

Artificial  intelligence  may  be  defined  as  the  branch  of  computer  science  that  is  concerned 
with  the  automation  of  intelligent  behavior.  AI  is  par*  of  computer  science  and,  as  such, 
must  be  based  on  sound  theoretical  and  applied  principles  of  that  field  These  principles 
incluGv.  the  data  .structures  used  in  knowledge  repre.sejitation,  the  algorithms  needed  to 
apply  that  knowledge,  and  the  language  and  programming  techniques  used  in  their 
implementation. 
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However,  this  definition  suffers  from  the  fact  that  intelligence  itself  is  not  very  well 
defined  or  understood.  Thus  the  problem  of  defining  artificial  intelligence  becomes  one 
of  defining  intelligence  itself.  (18:1) 


Because  of  the  mystique  formerly  associated  with  AI,  there  is  a  lingering  tendency  to  still 
believe  the  old  adage  ^Tt’s  an  AI  problem  if  it  hasn’t  been  solved  yet”  (10:1).  Professor 
Edward  Feigenbaum  of  Stanford  University,  an  early  pioneer  of  expert  systems  technology,  has 
defined  an  expert  system  as  an  computer  program  that  uses  knowledge  and  inference  procedures 
to  solve  problems  that  are  difficult  enough  to  require  significant  human  expertise  for  their  solution.” 

That  is,  an  expert  system  is  a  computer  system  which  emulates  a  small  aspect  of  the  decision¬ 
making  ability  of  a  human  expert.  The  term  emulate  means  that  the  expert  system  is  intended  to 
act  as  much  as  possible  respects  in  the  problem  domain  like  a  human  expert.  An  emulation  is  much 
stronger  than  a  simulation  which  is  only  required  to  act  like  the  real  thing  in  some  respects  (10:1). 
Internally,  the  expert  system  consists  of  two  main  components.  The  knowledge-base  contains  tlie 
knowledge  with  which  the  inference  engine  (algorithm)  draws  conclusions.  These  conclusions  are 
^he  expert  system’s  responses  to  the  user’s  queries  for  expertise.  As  more  knowledge  is  added  to 
the  intelligent  assistant,  it  acts  more  like  an  expert  (matching  patterns  is  a  logical  fashion  following 
the  experts  explicit  reasoning  that  has  been  programmed).  An  expert’s  knowledge  is  specific  to  one 
problem  domain  as  opposed  to  knowledge  about  general  problem-solving  techniques.  General 
problem  domains  are  medicine,  finance,  science  or  engineering  and  so  forth  in  which  an  expert  can 
solve  specific  problems  very  well.  The  expert’s  knowledge  about  solving  specific  problems  is  called 
the  knowledge  domain  (data  structure  and  control  structure)  of  the  expert  (10:3). 

Similarly,  according  to  huger: 

An  ..Xpert  system  is  a  knowledge-based  program  that  provides  “expert  quality”  solutions 
to  problems  in  a  specific  domain.  Generally,  its  knowledge  is  extracted  from  human 
experts  in  the  domain  and  it  attempts  to  emulate  their  methodology  and  performance. 

As  with  skilled  humans,  expert  systems  tend  to  be  specialists,  focusing  on  a  narrow 
set  of  problems.  Expert  systems  neither  copy  the  structure  of  the  human  mind  nor 
are  mevhani.sms  for  general  intelligence.  They  are  practical  programs  that  use  heuristic 
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Figure  2.  Basic  Concept  of  an  Expert  System  Function 


strategies  based  on  a  certain  set  of  algorithms  developed  by  humans  to  solve  specific 
classes  of  problems  (18:291)(23). 


A  concept  figure  of  an  expert  system  function  is  shown  in  Figure  2. 

The  process  of  building  an  expert  system  is  called  knowledge  engineering.  Knowledge 
engineering  refers  to  the  acquisition  of  knowledge  from  a  human  expert  or  other  source  and  to  the 
art  and  science  of  crafting  these  expert  systems(12:l-2).  It  applies  to  all  levels  of  the  software  life 
cycle.  But  for  the  reasons  mentioned  earlier,  it  emphasizes  the  requirements  phase.  An  expert 
system  has  the  following  performance  characteristics: 

♦  High  performance.  The  system  must  be  capable  of  responding  a'^  a  level  of  competency  equal 
to  or  better  than  an  expert  in  the  field.  The  term  better  means  that  the  system  will  never 
forget  things,  getting  tired,  make  mistakes,  like  a  human  expert  does. 

♦  Adequate  response  time.  The  system  must  also  perform  in  a  reasonable  time,  comparable  to 
the  time  required  by  an  expert  to  reach  a  decision. 

♦  Good  reliability.  The  expert  system  must  be  reliable  and  not  prone  to  crashes  (giving  false, 
slow  or  no  results)  or  else  it  will  not  be  used. 
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Figure  3.  Development  of  an  Expert  System 

♦  Understandable.  The  sysU.  should  have  an  explanation  capability  (pattern  matching)  in  an 
equivalent  way  that  human  experts  can  explain  their  reasoning.  (10:6-9) 

The  general  stages  in  the  development  of  an  expert  system  are  illustrated  in  Figure  3. 

Expert  System  Tools.  An  expert  system  tool  is  any  computer  language  or  programming 
system  that  supports  the  encoding  of  domain  knowledge  and  provides  one  or  more  inference  tech¬ 
niques  (search-methods;  select,  match,  act)  to  apply  the  knowledge  in  order  to  solve  the  problem 
(16:5).  The  structure  of  a  Rule-Based  Expert  System  is  illustrated  in  Figure  4. 

CLIPS  (C  Language  Integrated  Production  System)  is  an  expert  system  tool,  CLIPS/Ada, 
the  same  tool  as  CLIPS  but  written  entirely  in  Ada,  is  selected  for  this  effort.  Since  CLIPS/Ada 
is  the  only  expert  system  tool  available  that  was  written  in  Ada  programming  language.  As  with 
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Figure  4.  The  Structure  of  a  Rule-Based  Expert  System 

most  expert  system  shells,  CLIPS/ Ada  already  provides  an  inference  engine  and  employs  a  forward 
chaining  reasoning  method  (1:128).  It  is  already  implemented  and  interfaced  into  the  SAtool  II 
Essential  Subsystem(16). 

History 

The  original  SAtool  was  developed  by  Steve  Johnson  (13).  SAtool  is  an  interactive  computer 
aided  software  engineering  (CASE)  tool  that  permits  the  creation  and  editing  of  IDEFo  diagrams 
based  on  the  Structured  Analysis  and  Design  Techniques  (SADT^).  In  fact,  SAtool  is  sometimes 
referred  to  as  a  ‘SADT  editor’.  Implemented  on  a  Sun-3  in  the  C  programming  language,  SAtool 
created  both  a  graphics  file  and  a  data  dictionary  file;  however,  no  syntax  checking  of  the  output 
was  provided.  The  user  would  have  to  manually  check  the  diagrams  and  is  highly  likely  to  neglect 
a  mistake. 

^SADT  is  a  trademark  of  SofTech,  Inc, 
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D.  H.  Jung  explored  the  idea  of  performing  syntax  checking  on  the  SAtool  output (14).  His 
research  focused  on  the  prototype  development  of  an  IDEFq  syntax  (language)  validation  tool 
which  is  an  expert  system  to  perform  a  syntax  validation  of  the  IDEFo  diagram.  The  IDEFo 
syntzoc  is  formalized  by  converting  SADT  diagram  constructs  to  predicate  logic  facts,  and  defining 
grammatical  rules  as  predicates  also.  The  research  describes  how  both  a  box  and  an  a’*row  are 
transformed  to  predicate  logic.  A  C  program  called  a  iranslaior  translates  the  IDEFo  diagram 
features  into  a  formal  predicate  logic  description  that  is  ‘readable’  by  the  expert  system.  The 
expert  system  includes  a  backward  chaining  inference  engine  -  BC3^,  which  uses  a  goal  driven 
inference  chain  supported  by  Prolog- 1.  a  chain  in  the  goal  driven  inference  process  is  a  sequences 
of  steps  traversed  from  a  hypothesis  back  to  the  facts  which  support  the  hypothesis(10:159).  BC3 
requires  facts  (knowledge)  to  be  represented  as  three-element  lists  of  the  form  [Object,  Attribute, 
Value]  which  are  normally  referred  to  as  OAV  triples.  Although  the  expert  system  is  successful  in 
performing  the  syntax  validation  of  the  IDEFo  diagram,  the  rules  only  check  a  limited  number  of 
IDEFo  features.  In  addition,  full  integration  with  SAtool  is  not  achieved,  since  the  fact  file  must 
be  transferred  to  a  separate  computer,  the  Z-248. 

Continuing  research  on  the  integration  of  an  expert  system  with  SAtool,  Inteak  Kim  generated 
an  expert  system  implemented  in  Quintus  Prolog  on  the  SUN-3(15).  The  entire  proce.ss  of  IDEFo 
diagram  creation,  editing,  and  error  checking  is  performed  on  the  SUN-3,  but  the  user  is  again 
required  to  run  two  separate  processes:  one  for  SAtool  and  one  for  Quintus  Prolog..  Cvt:n  the  rule 
base  of  the  expert  system  is  extended  to  include  rules  for  several  additional  features  of  the  IDEFo 
language,  and  the  need  for  the  separate  microcomputer  to  run  the  expert  system  is  also  eliminated. 
However,  fully  transparent  integration  is  still  not  achieved  due  to  software  compatibility  problems 
between  the  C  language  and  Quintus’s  version  of  Prolog.  Besides,  the  data  in  an  (0  A  V]  tuple  is 
limited  to  have  only  three  fields  introducing  extra  complexity  in  mapping  the  IDEFo  syntax  to  the 
expert  system  rules. 

^BC3  is  a  Prolog  backward  chaining  expert  .system  shell  developed  by  F.  M.  Brown. 
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Overlaping  with  the  work  of  Kim,  Terry  Kitchen  and  Jay  Tevis  jointly  designed  the  essential 
model  and  graphics  editor  model  for  the  Ada  based  SAtool.  The  research  goal  was  to  develop 
an  object  based  Ada  CASE  tool  (SAtool  II)  using  the  abstract  data  model  as  the  requirements 
document  (16)  (28). 

SAtooHI  has  shown  that  an  Ada  based  expert  system  to  check  the  syntax  of  an  IDEFo 
diagram  is  feasible  as  a  part  of  that  system,  thus  the  effectiveness  and  efficiency  of  the  developing 
tool  is  to  be  evaluated.  At  present,  a  generic  Ada  based  expert  system  tool  (shell),  CLIPS/Ada  is 
already  implemented  and  interfaced  into  the  Essential  Subsystem,  where  the  subsystem  is  the  part 
of  SAtool  II  that  defines  the  data  structure  of  the  user  input  data.  The  visibility  of  the  CLIPS/Ada 
with  the  Essential  Subsystem  is  illustrated  in  Figure  5(16). 

Problem  Siaiemeni 

The  feasibility  of  using  an  Ada  based  expert  system  has  been  shown  in  SAtool  II.  However, 
the  translation  of  a  user’s  hierarchical  IDEFq  diagram  to  a  facts  file  is  not  complete,  this  file  can  be 
loaded  into  the  working  memory  together  with  the  CLIPS/Ada  rules  to  check  its  syntax.  Also,  the 
rules  for  checking  the  syntax  are  incomplete.  Thus,  the  system  is  not  able  to  perform  the  function 
of  checking  the  syntax  information  in  a  user  developed  hierarchical  IDEFo  diagrams  with  SAtool 
II. 

This  research  investigation  focuses  on  continuing  the  fact  translation  procedures,  expanding 
SADT  syntax  checking  rules  and  making  the  Ada  based  expert  system  of  the  SAtool  II  to  a  testing 
phase.  Further  investigations  could  be  made  to  improve  its  efficiency  or  reevaluate  its  applicability 
to  the  current  project. 

Assumptions 

Several  assumptions  must  be  made  at  the  outset  of  this  research. 
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L  CLIPS/ Ada  is  an  Ada  version  of  CLIPS  which  has  all  the  original  functionality  of  CLIPS 
with  a  few  exceptions(16).  CLIPS/Ada  has  already  implemented  as  a  part  of  the  essential 
subsystem  as  the  data  driven,  forward  chaining  inference  engine  for  the  Syntax  Checking 
Expert  System. 

2.  Concurrent  research  work  with  the  drawing  data  model  and  related  SAtool  II  implementation 
issues  initiated  by  (28)  can  proceed  at  a  pace  that  does  not  hinder  this  concurrent  research. 
The  drawing  data  model  is  expected  to  implement  the  screen  layout  and  drawing  functions 
to  be  integrated  with  the  essential  model. 

3.  Users  and/or  researchers  planning  to  utilize  this  work,  must  be  familiar  with  the  concepts  of 
modeling  software  requirements  using  IDEFq,  SA,  or  SADT. 

Research  Approach 

The  following  steps  outline  the  intended  research  approach: 

1.  Analyze  the  IDEFo  diagram  syntax.  “Translate”  all  the  information  that  might  appear  in 
the  structures  including  illegal  ones  into  a  facts  knowledge  format  that  can  be  accepted  by 
CLIPS. 

2.  Complete  the  SAtool  II  Ada  program  to  perform  the  functions  in  (1)  to  retrieve  all  the  facts 
stored  in  the  essential  model. 

3.  Complete  the  Ada  program  to  restore  all  the  facts  back  to  the  essential  data  structure. 

4.  Complete  the  IDEFq  CLIPS  rule  base  that  checks  the  facts  that  are  translated  from  the  users 
diagrams  and  subsequently  loaded  into  working  memory  of  CLIPS. 

5.  Demonstration  programs  will  validate  that  the  CLIPS  expert  sy.stcm  and  fact  translation 
procedures  works. 


6.  Selection  and  use  in  ES  application. 


Materials  and  Equipment 


The  essential  subsystem  of  SAtool  II  is  already  implemented.  The  CLIPS/Ada  is  also  inte- 
jsrrated  into  the  subsystem.  The  target  environment  for  the  integration  to  occur  is  the  SUN-4  work¬ 
station  running  a  version  of  Berkeley  Unix  OS.  Several  workstations  are  readily  available  within 
the  Department  of  Electrical  and  Computer  Engineering  to  accomplish  this  research.  The  SUN-4 
is  the  chosen  platform,  because  it  is  the  most  readily  available  workstation  with  the  X-window  vs 
sunview  graphics  capability  within  the  department. 

Scope  and  Limitations 

1.  The  development  of  subprograms  within  the  name  subsystem  will  translate  information  stored 
in  the  essential  data  model  data  structures  into  facts  suitable  for  loading  into  the  working 
memory  of  the  CLIPS  expert  system  shell. 

2.  The  development  of  subprograms  within  the  subsystem  will  restore  all  the  facts  from  the  facts 
file  and  load  them  back  to  the  essential  data  model  data  structure.  Thus  each  facts  file  could 
be  separately  stored,  modified,  and  perform  syntax  checking  in  the  essential  model. 

3.  The  development  of  an  independent  rules  file  will  perform  the  syntax  checking  functions.  This 
is  to  be  inferenced  by  the  CLIPS/Ada  already  integrated  into  the  essential  model. 

4.  The  integration  of  the  SAtool  II  subsystems  with  tlie  drawing  model  of  SAtool  II. 

Sequence  of  Pre$e7itaiion 

This  thesis  is  designed  to  be  organized  into  6  chapters.  A  short  introduction  to  the  lOEFo 
language  and  all  the  related  terms  arc  explained  in  chapter  1.  A  history  of  this  research  and  its 
feasibility  is  discussed  in  chapter  2,  literature  review. 

Chapter  3  presents  a  review  of  the  requirements  for  the  subsystem,  the  essential  model  spec¬ 
ifications  and  data  .structures,  the  expert  system  rationale  and  example.s.  The  facts  tran.^ilator 
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requirements  and  the  relationship  between  the  facts  in  a  file  with  the  working  memory,  and  the 
facts  in  the  working  memory  with  the  expert  system  rules  are  also  presented.  In  addition,  the 
syntax  checking  expert  system  requirements  will  be  specified. 

Chapter  4  presents  the  design  of  all  the  required  subsystems  and  files  to  be  implemented  into 
the  essential  subsystem. 

Chapter  5  illustrates  the  completion  of  the  design  and  also  includes  the  implementation, 
compiling  and  testing  of  the  subsystem. 

Finally,  Chapter  6  presents  a  summary  of  the  thesis  work  plus  some  conclusions  and  recom¬ 


mendations. 


//.  LITERATURE  REVIEW 


Iniroduciion 

The  final  goal  of  this  thesis  investigation  is  to  design  and  implement  an  Ada  based  expert 
system  formulation  as  a  subsystem  for  checking  the  syntax  of  IDEFo  diagrams  derived  from  the 
essential  model  of  SAtool  11.  Since  the  IDEFo  language  (20)  is  implemented  by  SAtool  II,  a  detailed 
overview  of  the  language  is  presented  in  this  chapter  and  a  hierarchy  of  IDEFo  example  diagrams 
are  shown.  Also  the  basic  ideas  of  CLIPS  is  introduced.  An  example  along  with  the  behavior  of 
CLIPS  execution  is  provided  in  Appendix  A. 

The  process  of  translating  the  IDEFo  models  into  facts  formats  from  their  SAtool  II  data 
structure  is  introduced.  It  is  initiated  by  (16).  But  most  of  the  functions  are  not  implemented. 
How  those  facts  are  to  be  used  by  the  CLIPS  expert  system  rule  base  is  explained. 

Finally,  the  Syntax  Validation  of  SAtool  II  will  be  explained. 

IDEFo 

The  main  concern  supporting  structured  analysis  (SA)  is  the  decomposition  of  a  complex 
problem  into  parts  that  can  be  more  easily  understood.  This  is  facilitated  by  a  hierarchical  ap¬ 
proach,  called  functional  decomposition,  in  which  a  major  problem  is  broken  down  into  its  major 
components,  then  each  of  them  is  in  turn  divided  into  its  major  pieces,  and  so  forth.  IDEFo  syntax 
is  a  derivative  of  the  SADT  syntzcc  and  is  used  for  software  requirements  analysis  (20). 

Although  a  decomposition  can  be  based  on  data  or  process,  IDEFo  is  based  on  the  analysis  of 
processes  or  acUviiies.  The  decomposition  is  reflected  through  a  series  of  Funciion  Diagrams  and 
corresponding  facing  page  ieziy  as  shown  in  Figure  7  through  Figure  13. 

An  IDEFo  system  model  consists  of  a  series  of  hierarchically  related  function  diagrams, 

along  with  text  descriptions  and  other  supporting  elements.  The  liierarchy  of  drawings 
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is  formed  by  starting  with  a  single  function  representing  the  system  being  modeled, 
and  successively  decomposing  each  function  into  its  major  subfunctions.  Thus  at  any 
given  level,  a  function  diagram  represents  a  single  function  of  the  next  higher  level, 
and  presents  the  major  subfunctions  of  that  parent  function,  along  with  the  interfaces 
between  those  subfunctions.(20:7) 

The  overall  objective  of  using  IOEFq  diagrams  is  the  creation  of  a  system’s  software  require¬ 
ments  model  Any  model  is  an  abstraction  of  reality,  with  many  details  omitted  and  only  the 
relevant  ones  included.  This  model  serves  two  purposes:  1.  to  develop  a  detailed  understanding  of 
the  user*s  requirements;  2.  to  provide  a  structured  documentation  of  the  software  requirements  for 
the  use  in  the  software  design  stage  of  the  life  cycle. 

As  mentioned  earlier  in  Chapter  1.  The  most  important  item  of  decomposition  in  IDEFo 
is  a  function,  which  is  represented  by  a  rectangular  box.  Since  a  function  represents  a  process 
or  action,  and  is  identified  by  a  name  that  starts  with  a  verb.  A  box  might  be  the  parent  of  its 
decompositions.  An  IDEFo  model  of  software  system  requirements  is  constructed  by  starting  with 
an  A-0  diagram  that  consists  of  a  single  box  and  a  number  of  arrows.  In  the  highest  level  diagram, 
the  single  box  represents  the  entire  system  and  might  be  decomposed  to  any  level  of  details.  Each 
box  on  a  diagram  may  be  decomposed  into  a  diagram  of  its  own.  It  is  equivalent  to  the  idea 
of  “context  diagram”  as  mentioned  in  (30:339)  which  is  a  part  of  the  DFD  modeling  technique. 
The  context  diagram  highlights  several  important  characteristics  of  the  system  similar  to  the  A-0 
diagram: 

♦  The  people,  organization,  or  systems  with  which  the  developed  system  communicates.  These 
are  known  as  terminators. 

♦  The  data  that  our  system  receives  from  the  outside  world  and  that  must  be  processed  in  some 
way. 

♦  The  data  produced  by  our  system  and  sent  to  the  outside  world. 
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Figure  6.  Components  of  a  Context  Diagram 


#  The  data  stores  that  are  shared  between  our  system  and  the  terminators.  These  data  stores 
a.c  either  created  outside  the  system  and  used  by  our  system  or  created  by  our  system  and 
used  outside  the  system. 

•  The  boundary  between  our  system  and  the  rest  of  the  world. (30:339) 

The  concept  of  a  context  diagram  is  shown  in  Figure  6. 

Even  the  idea  of  IDEFq  diagram  and  context  diagram  are  equivalent.  Each  function  box  in  an 
IDEFo  diagram  must  have  at  least  one  control  data  and  one  output  data,  the  input  and  mechanism 
numbers  are  optimal.  Those  are  not  shown  in  the  context  diagrams.  The  resulting  functions,  data 
manipulations  of  the  model  represented  in  IDEFo  diagrams  is  more  explicit  than  that  of  the  context 
diagrams.  Which  means  easier  to  understand  and  implement.  Thus  IDEFo  diagrams  are  .selected 
for  this  discussion. 

In  a  hierarchy  of  IDEFo  diagrams.  Level  A-0  (pronounced  A  minus  zero)  Diagram  is  also 
known  as  the  environment  models  as  it  represents  the  interface  between  what  is  being  modeled  or 
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analyze;)  and  its  environment.  It  is  used  to  define  the  scope  of  the  system.  In  most  cases,  A-0  is 
the  highest  level  considered. 

Since  the  A-0  diagram  lacks  the  necessary  detail  to  describe  the  requirements  and  functions  of 
the  system  being  developed,  it  must  be  decomposed  into  lower  level  diagrams  forming  a  hierarchy, 
where  each  lower  level  in  the  hierarchy  reveals  greater  detail. 

Figure  7  shows  the  hierarchy  of  the  example  IDEFq  model  for  ^^ControlJElevator” .  Therefore, 
each  diagram  in  the  model,  with  the  exception  of  the  A-0  diagram,  is  essentially  a  functional  de¬ 
composition  of  a  box  in  a  higher  level  diagram.  The  box  in  the  higher  level  diagram  is  appropriately 
called  the  parent  box  of  the  diagram. 

The  first  actual  level  of  decomposition  is  the  ‘‘Level  AO  Diagram,”  a  separate  drawing  which 
represents  the  same  level  of  analysis  as  the  A-0  diagram,  but  which  shows  the  major  subfunctions 
of  the  system  being  investigated.  Since  it  is  the  same  level,  the  external  interfaces  on  this  drawing 
should  be  the  same  as  in  the  A-0  diagram,  in  addition  to  the  interfaces  between  the  subfunctions. 
Each  box  on  the  diagram  is  given  an  integer  number,  beginning  with  “1,”  but  the  actual  function 
numbers  are  “Al,  A2,...”  at  this  level.  The  numbers  are  relative  to  each  particular  box  and  the 
actual  function  number  of  a  box  is  its  integer  appended  to  the  function  number  of  its  parent.  It  is 
used  to  track  consistency  between  levels. (30:24-30).  Furthermore,  each  and  every  box  in  an  IDEFo 
diagram  must  have  at  least  one  control  arrow  and  one  output  arrow.  No  restrictions  exist  on  the 
number  of  input  or  mechanism  arrows  permitted. 

For  more  details  concerning  about  the  IDEFo  modeling  technique  refer  to  the  manual  (20). 

Figure  8  illustrates  a  single  IDEFo  diagram  that  represents  the  essential  model  for  an  elevator 
scheduler  and  controller.  Figure  9  through  13  shows  the  decomposition  diagrams  simplified  and 
translated  into  IDEFq  diagrams  from  (30:631-652)  as  an  example.  Since  the  functions  of  creating 
a  data  dictionary  has  not  been  implemented  for  the  es.sential  model,  so  the  discussion  for  that  is 
omitted  here. 
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Figure  7.  Hierarchy  Diagram  for  ‘Control  EMevator’ 
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Figure  8.  A-0  Essential  Model  Diagram  for  ‘Control  Elevator’ 
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Figure  9.  AO  Diagram  for  ‘Control  Elevator’ 
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Figure  10.  A1  Diagram  for  ‘Control  Elevator* 


25 


Figure  11.  A12  Diagram  for  ‘Control  Elevator’ 
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Figure  12.  A2  Diagram  for  ‘Control  Elevator’ 
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F'igure  13.  A26  Diagram  for  ‘Control  Elevator’ 
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Iniroduciion  to  CLIPS 


To  my  knowledge  so  far,  there  are  many  practical  aspects  of  building  expert  systems  which 
must  be  learned  by  doing.  Those  aspects  include,  to  say  the  least,  the  ability  of  defining  a  problem, 
the  knowledge  to  approach  the  solution  of  that  problem,  the  proficiency  in  using  the  expert  system 
tools,  tlie  ability  to  reason  under  uncertainty,  and  finally  the  skills  to  implement  that  knowledge  into 
an  expert  system.  So  far,  building  an  expert  system  is  much  like  writing  a  program  in  a  procedural 
language.  We  have  learned  a  lot  of  theories  and  algorithms  for  procedural  languages  at  AFIT.  But 
knowing  how  an  algorithm  works  is  not  equivalent  to  being  able  to  write  a  procedural  program  to 
perform  that  algorithm.  Due  to  the  fact  of  the  complexity  of  the  problem,  it  is  not  always  possible 
for  a  software  designer  to  build  a  system  that  will  reflect  all  the  intuitions  the  designer  intended 
to  implement.  But  the  final  product  should  be  maximized  on  its  functions  in  accordance  with 
the  understanding  of  the  problem  and  the  design  techniques  of  the  software  developer.  Similarly, 
capturing  an  expert’s  knowledge  is  not  equivalent  to  building  an  expert  system.  For  this  reason, 
practical  experience  in  using  an  expert  system  tool  is  invaluable  in  learning  about  expert  systems. 
In  addition  to  the  inadequacies  mentioned  in  Chapter  1  for  using  [0  A  V)  triples  to  repre.sent  facts 
of  the  IDEFo  model  diagrams.  CLIPS,  which  means  C  Language  Integrated  Production  System  is 
introduced  here.  The  basic  elements  of  CLIPS  are  (10:373): 

1.  fact-list:  global  memory  for  data.  Each  fact  is  a  chunk  of  information  in  CLIPS.  A  fact 
consists  of  one  or  more  fields  enclosed  in  matching  left  and  right  parentheses. 

2.  knowledge-base:  contains  all  the  rules.  Rules  can  be  typed  directly  into  CLIPS  or  they  can 
be  loaded  in  from  a  file  of  rules  created  by  an  editor.  Each  rule  is  of  the  form: 

(defrule  name-of-the-rule 

LHS-of-the-rule  (conditions) 

=> 

RHS-of-the-rule  (actions) 
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Where  LHS 
=> 

RHS  logically  implies: 

if  LHS(CondHion$),...  THEN  RHS(Aciion$)....  All  the  LHS  conditions  are  logically  and^ed 
together. 

3.  inference  engine:  controls  overall  execution,  applying  all  the  rules  to  the  fact-list  and  derive 
expert  results.  It  can  be  a  combinatorial  search  process. 

CLIPS  is  a  forward  chaining  rule-based  language  that  has  inferencing,  pattern  matching, 
state  searching,  and  representation  capabilities.  The  design  of  CLIPS  is  such  that  rules  only  match 
facts  that  have  been  entered  after  the  rules.  Thus  newly  entered  rules  will  not  match  the  facts  that 
are  currently  on  the  fact-list.  Only  new  facts  that  are  entered  will  be  seen  by  the  rule.  This  means 
that  a  rule  can  only  be  activated  by  facts  that  are  asserted  after  the  rule  is  entered,  thus  during 
the  execution,  after  new  facts  are  asserted  as  a  result  of  some  rules  firing,  then  it  might  activate 
existing  rules  that  were  not  matched  before  (10:373-387). 

Essential  Model  of  the  IDEFo  Abstract  Data  Model. 

The  subsystems  of  the  essential  model  which  are  already  partially  implemented  but  not  com¬ 
plete  include: 

♦  The  necessary  data  structures  to  hold  the  essential  data  model  state  information. 

•  The  storing  and  restoring  of  essential  data  model  state  information  which  is  in  the  form  of 
CLIPS/Ada  facts. 

♦  the  capability  to  create  one  or  more  data  dictionary  entries. 

•  The  capability  to  check  the  syntax  of  an  IDEFo  model  by  means  of  a  rule  ba.se  consisting  of 
IDEFo  syntactical  checking  rules(16). 
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Facts  utilities.  The  storing  and  restoring  of  essential  data  model  state  information  in  the 
form  of  CLIPS/Ada  facts  is  performed  by  a  separate  file  EssenttaLFacLUtiliiies.  The  file  is  an 
“iterator”  performed  by  a  set  of  operations  that  iterates  through  the  data  structure  of  the  essential 
model  (3:52-62). 

Through  precisely  defined  formats  of  the  output  file,  the  informations  from  the  entire  essential 
data  model  (i.e.,  the  project)  is  retrieved  and  stored  as  a  CLIPS/Ada  readable  file  format: 
(attribute  object  value,  value,..:.) 

Where  attribute  defines  the  type  of  fact,  object  is  the  actual  name  of  the  data,  and  values  are  a 
set  of  descriptions  of  the  object  with  unlimited  length  but  each  value  must  be  separated  by  one  or 
more  spaces;  i.e.,  (project-name  Project_Name)  where  capitalized  identifiers  in  the  parenthesized 
fact  file  represents  information  derived  for  the  data  structure  of  the  essential  model.  Since  each 
project  is  stored  in  the  form  of  facts  file.  A  set  of  restore  functions  is  also  needed  to  restore  the 
facts  format  back  into  the  IDEFo  essential  data  model,  thus  we  don’t  need  to  regenerate  the  model 
again. 

Of  particular  interest  is  the  two  different  groups  of  facts:  syntactical  facts,  and  stat  repre¬ 
sentation  facts.  Syntactical  facts  are  those  sent  to  the  CLIPS  working  memory  for  syntax  checking, 
whereas  state  representation  facts  simply  represent  the  sate  of  the  IDEFq  model.  The  reason  for 
this  is  that  the  syntax  checking  rules  does  not  need  to  know  the  detail  of  some  data  value,  simply 
to  check  if  it  is  there. 

CLIPS  Working  Memory  Interface  and  Rules  File.  The  CLIPS  Working  Memory  Interface 
provides  the  interface  for  the  Essential  Subsystem  to  the  CLIPS/Ada  expert  system.  It  is  the  only 
package  in  SAtool  II  that  has  visibility  to  the  CLIPS/Ada  expert  .system  operations.  When  the 
check  syntax  option  is  .selected  by  the  u.ser  in  the  essential  model,  the  facts  file  and  another  separate 
rules  file  are  loaded  into  CLiPS  Working  Memory  and  CLIPS/Ada  initiates  the  logical  .sequence 
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to  show  the  syntactical  checking  results  of  the  created  IDEFq  model.  It  is  an  interface  designed  by 
(16). 

The  rules  file  is  to  be  expanded  and  tested  as  an  integral  part  of  the  essential  model. 

Expert  Systems. 

In  the  process  of  building  an  expert  rule  system  using  an  expert  system  shell,  we  are  following 
a  step  by  step  method  of  building  a  program(10:419). 

♦  First:  pseudo  rules  were  written  using  English-like  text. 

♦  Second:  the  pseudo  rules  were  used  to  determine  the  types  of  facts  that  would  be  required. 
Templates  describing  the  facts  were  designed,  and  the  initial  knowledge  (facts)  was  coded 
using  these  templates. 

♦  Finally:  the  pseudo  rules  were  translated  to  CLIPS  rules  using  the  fact  templates  as  a  guide 
for  translation. 

To  show  how  this  works,  an  example  from  (10:413-^419)  was  introduced  and  its  behavior  during 
CLIPS  execution  is  shown  as  explained  in  Appendix  A:  CLIPS  BEHAVIOR  IN  THE  BLOCKS 
WORLD. 

Integration  of  Expert  Systems  with  CASE  Tools. 

Through  examining  and  understanding  the  projects  developed  from  different  perspectives,  the 
strengths  and  weakness  of  each  project  can  be  identified  for  future  reference.  Today,  expert  .systems 
are  built  on  a  variety  of  software  and  hardware  platforms.  Because  of  these  various  platforms, 
AFIT,  academia,  and  industry  have  begun  both  theoretical  and  actual  development  of  systems  that 
integrate  CASE  tools  with  expert  system.  Each  of  the  following  projects  have  been  implemented 
with  differing  degrees  of  succe.ss. 
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SAiool  with  Syntax  Validation, 


As  mentioned  previously,  SAtool  (13)  is  simply  a  graphical  editor  and  provides  no  advice  or 
assistance  to  the  user  as  the  IDEFq  diagrams  are  being  drawn.  In  other  words,  the  user  of  SAtool 
could  not  determine  if  the  finished  diagram  is  consistent  with  the  IDEFq  graphical  language  except 
by  tedious  and  time  consuming  manual  inspection.  To  improve  this,  Jung  initialized  the  idea  of 
syntax  checking  ability  with  SAtool  in  his  MS  thesis  in  1988  (14)  His  research  focused  on  the 
prototype  development  of  an  IDEFq  syntax  (language)  validation  tool  which  is  an  expert  system  to 
perform  a  syntax  validation  of  an  IDEFq  diagram.  The  IDEFq  syntax  is  formalized  by  converting 
the  syntax  to  predicate  logic  facts.  The  research  describes  how  both  a  box  and  an  arrow  are 
described  in  predicate  logic. 

The  graphical  feature  BOX  is  translated  into  the  predicate  BOX(x),  which  means;  x 
is  a  BOX.  In  the  case  of  the  ARROW,  it  is  translated  into  the  predicate  ARROW(x), 
which  means:  x  is  an  ARROW  (16:28) 

There  are  two  steps  to  the  syntax  validation  tool  (16:28)  First,  a  C  program  was  devel¬ 
oped  called  a  translator  to  translate  the  IDEFq  diagram  features  into  a  formal  description  that  is 
‘readable’  by  the  expert  system.  The  expert  system  is  a  backward  chaining  expert  system-BCS^ 
however,  required  facts  had  to  be  represented  as  three-element  lists  of  the  form  [Object,  Attribute, 
Value]  which  are  normally  referred  to  as  OAV  triples.  The  IDEFq  diagram  representation  is  stored 
in  multiple  C  data  structures,  and  the  translator  program  creates  a  file  of  facts  based  on  the 
information  in  those  structures  (16:28) 

The  second  and  final  step  of  the  syntax  validation  tool  is  the  syntax  checker  (16:28)  The 
syntax  checker’s  purpose  is  to  check  tlie  IDEFq  diagram  (now  represented  as  OAV  triples)  for 
syntactical  errors,  the  syntax  checker  is,  in  essence,  the  expert  system.  Syntax  rules  such  as  “Each 
box  must  have  a  name”  and  “Each  arrow  must  have  a  label”  are  converted  to  if., ..then  constructs 

*BG3  is  a  Prolog  backward  chaining  expert  system  shell  developed  by  F.M.  Brown. 
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in  a  form  acceptable  to  BC3.  The  syntax  checker,  when  executed,  produces  error  messages  for  the 
designer  to  review  and  take  corrective  action. 

The  research,  however,  was  limited  in  scope.  All  the  features  of  an  IDEFq  diagram  are  not 
addressed.  Plus,  a  transparent  integration  of  SAtool  and  the  syntax  validation  tool  was  not  achieved 
(i.e.,  a  manual  step  remained). 

Both  the  aforementioned  integration  problem  as  well  as  expanding  the  syntactical  checks 
that  the  expert  system  performed  were  resol ved(  16:29).  The  number  of  IDEFq  syntactical  features 
checked  by  the  expert  system  are  expanded  (16:29).  To  resolve  the  integration  problem,  an  attempt 
was  made  to  integrate  SAtool  with  a  Quintus  Prolog  implementation  of  the  syntax  validator  (the 
expert  system).  The  “new”  syntax  validator  is  simply  the  expert  system  shell  BC3  with  changes 
necessary  for  it  to  run  under  Quintus  Prolog.  Unfortunately,  compatibility  problems  between  Quin¬ 
tus  Prolog  and  the  C  programming  language  result  in  a  failure  to  achieve  a  transparent  integration 
of  the  expert  system  with  SAtool  (16:29). 

Currently,  a  more  capable  CASE  tool,  SAtool  II  is  being  developed  in  the  Ada  programming 
language  and  includes  an  Ada  based  expert  system  using  CLIPS/Ada.  Terry  and  .Jay  continued  the 
effort  of  developing  the  Essential  model  and  Drawing  Model  of  SAtool  II  (16)  (28)  As  mentioned 
earlier,  the  Essential  Model  designed  and  implemented  by  Terry  needs  to  be  expanded  to  complete 
its  expert  system  functions. 

SpeaficaUoii-Transformaiion  Expert  System  (STBS).  At  the  University  of  Illinois,  Tsai  and 
Ridge  have  developed  the  Specification-Transformation  Expert  System  (STES)  which  is  an  expert 
system  that  they  have  integrated  with  the  CASE  tool  Teamwork  developed  by  Cadre  Technolcgies 
(29:3d).  Teamwork  is  u.sed  to  create  DFDs.  In  addition,  Teamwork  runs  on  an  Apollo  worl  .station 
platform  and  includes  a  built-in  Access  tool  which  allows  users  to  access  the  underlying  data 
structures  that  contain  the  DFD  description.  In  this  case,  a  C++  program  was  written  by  Tsai 
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and  Ridge  to  access  the  DFD  description  (29:34).  By  implementing  the  STBS  in  OPS5,  which  can 
also  run  on  Apollo  workstations,  transparent  integration  of  Teamwork  and  STBS  is  achieved. 

After  the  requirements  analysis  phase  of  the  software  development  life  cycle  is  completed, 
STBS  can  be  used  in  the  next  step  —  the  design  phase.  STBS  assists  the  software  engineer  with 
the  design  phase  by  transforming  the  DFD  into  a  struct'ue  chart  (16:2).  The  STBS  is  used  to 
examine  the  C++  representation  of  the  DFDs,  extracts  the  salient  features,  and  converts  them 
into  production  rules.  The  STBS  then  “applies  inference  to  identify  and  transform  the  efferent, 
afferent,  and  transformation-centered  components  of  the  dataflow  diagram  into  a  first-cut  structure 
chart”  (16:29-30). 

Visible  Analyst  Workbench.  Visible  Analyst  Workbench  ^  is  an  IBM-PC  based  CASE  tool 
marketed  by  Visible  Systems  Corporation  that  contains  rales  to  perform  error  checking  of  DFDs 
(16).  According  to  the  product  documentation,  the  CASE  tool  portion  called  Visible  Analyst 
allows  the  user  the  choice  of  two  different  styles  in  DFD  construction:  the  Yourdon/DeMarco 
Method  ^  DFD  or  the  Gane  and  Sarson  Method  DFD  (16*29-30).  Unlimited  levels  of  DFD  process 
decomposition  are  also  supported.  Regardless  of  the  style  cliosen,  however,  the  rules  portion  of  the 
tool  called  Visible  Rules  can  check  the  diagram  for  proper  balancing,  naming  conventions,  etc  (16). 

The  Visible  Rules  are  executed  without  leaving  the  DFD  which  means  transparent  integration 
between  the  CASE  t^ol  portion  and  the  “expert  system”  portion  is  achieved.  Although  the  word 
rules  implies  a  rule-based  expert  system  is  used,  the  proprietary  nature  of  the  product  does  not 
permit  the  disclosure  of  whether  the  rules  are  implemented  algorithmically  or  by  an  expert  system 
paradigm. 

^Visible  Analyst  is  a  registered  trademark  of  Visible  Systems  Corporation. 

®Tlie  correct  rcfeieiice  should  probably  be  VSM  1.0  (5). 
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Summary 


This  chapter  provides  a  review  of  several  subject  matter  areas  that  directly  relate  to  this 
investigation.  More  detailed  IDEFo  syntax  was  explained.  Also  the  basic  structure  of  CLIPS  was 
stated.  The  Essential  Model  of  SAtool  II  is  described  along  with  its  subsystems  to  gain  insight  into 
an  expert  system  functions.  An  actual  example  is  provided  in  Appendix  A  to  show  the  execution 
of  CLIPS  program.  Thus  a  user  of  SAtool  II  unfamiliar  with  CLIPS  execution  might  be  able  to 
understand  the  behavior  of  the  expert  system  through  the  study  of  this  example.  Presented  are  the 
format  of  facts  and  rules  and  the  behavior  of  applying  rules  on  those  facts  in  the  working  memory 
during  execution. 

Several  examples  concerning  the  integration  of  CASE  tools  with  expert  systems  are  also 
reviewed,  since  this  research  calls  for  a  similar  integration.  Clearly,  all  attempts  at  integration  do 
not  succeed.  To  improve  the  chances  of  successful  integration,  information  from  successful  projects 
should  be  obtained  and  used  as  a  foundation  for  further  research.  The  integration  of  IDEFo  syntax 
checking  capabilities  in  SAtool  II  using  an  expert  system  is  the  key  concern  of  this  research. 
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HI.  REQUIREMENTS  ANALYSIS 


Introduction 

This  chapter  presents  a  review  of  the  requirements  for  the  subsystem  to  be  integrated  with 
SAtool  IL  First,  the  IDEFq  Diagram  Translator  is  implemented  as  a  separate  package  and  Essential 
Fact  Utilities  is  used  to  translate  any  IDEFq  diagrams  drawn  by  SAtool  II  into  a  set  of  CLIPS 
readable  facts  format.  The  second  category  is  to  design  and  implement  the  IDEFq  Syntax  Expert 
System  which  is  to  be  an  application  of  a  knowledge-based  expert  system.  It  is  also  a  separate  file 
having  access  only  to  the  CLIPS  working  memory  in  the  essential  model. 

This  chapter  presents  the  considerations  related  to  the  development  of  the  IDEFq  Diagram 
Translator  requirements,  IDEFq  Syntax  Expert  System  requirements,  formalization  criteria,  the 
expected  results,  and  validation  test  requirements. 

Consideration  of  the  Previous  Studies 

As  mentioned  in  (15),  the  syntax  checking  ability  was  provided  to  find  any  inconsistencies 
for  boundary  arrows  with  the  parent  IDEFq  diagram.  But  as  mentioned  earlier,  Object,  Attribute, 
Values  data  structure  were  used  to  represent  the  IDEFq  diagrams  known  as  OAV  triples.  Also, 
compatibility  problems  between  Quintus  Prolog  for  syntax  checking,  and  the  C  programming  lam 
guage  for  IDEFq  diagrams  translator,  resulted  in  a  failure  to  achieve  the  transparent  integration 
of  the  expert  system  with  SAtool.  Thus  the  tool  developed  in  (15)  must  currently  run  the  systems 
separately.  This  means  the  facts  translated  from  the  IDEFq  diagrams  must  be  generated  and  then 
the  inference  process  could  begin  for  the  syntax  checking  abilities. 

Here,  our  purpose  is  to  develop  a. system  based  on  Ada.  The  translator  is  to  be  written  in  Ada 
and  the  expert  system  tool  is  also  to  be  in  Ada,  CLIPS/Ada.  Once  the  .subsystems  are  integrated 
into  a  whole,  the  system  should  provide  a  CASE  tool  environment  for  SAtool  11. 
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Fads  Translator  Requiremenis-EsseniiaLFacHJiiliiies. 


Six  different  mechanisms  or  manager  mechanisms  are  already  implemented  in  the  essential 
model  for  the  seven  different  object  classes.  The  six  manager  mechanisms  are: 

1.  Activity-Manager 

2.  DataJElement-Manager 

3.  Consists-OLRelation-Manager 

4.  Historical-Activity-Manager 

5.  Calls-Relation-Manager 

6.  ICOM-Relation-Manager  (16:64) 

The  IDEFo  Diagram  Translator  is  implemented  as  a  separate  file  to  be  completed  and  integrated 
with  the  Essential  Subsystem.  It  must  have  the  following  two  functions: 

♦  Retrieve  procedures 

•  Restore  procedures 

Retrieve  Essential  Data  Model  Information.  The  information  that  is  stored  in  the  manager 
abstract  state  machine  represents  the  essential  part  of  an  IDEFo  model.  This  information  must  be 
extracted  from  the  manager  for  output  to  a  file  or  for  input  to  the  CLIPS/Ada  working  memory 
for  syntax  checking.  This  is  accoi.  plisbcd  by  a  package  containing  a  serious  of  Retrieve  (Aciiviiy, 
Data.Elemeni  ...I  COM -Relation)  Facts  procedures.  Those  procedures  first  examines  the  ‘Type 
Facts  Flag’.  Based  on  the  flag  setting  (T  or  F),  the  procedure  retrieves  one  of  two  different  sets 
of  facts  and  inserts  them  into  a  Fact.Manager  which  is  an  instance  of  the  Fact  Buffer. Package.  If 
the  flag  is  true,  only  facts  for  the  expert  system  arc  inserted  in  the  Fact-Manager.  If  the  flag  is 
false,  only  the  facts  necessary  to  permanently  store  the  state  of  the  essential  data  model  (i.e.,  the 
IDIOFo  model)  are  inserted  into  the  Fact-Manager.  This  procedure  is  invoked  b\  a  client  program 
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whenever  the  user  saves  the  project  he/she  is  working  on,  or  when  the  user  wishes  to  check  the 
syntax  of  the  project  (i.e.,  the  current  IDEFo  model)  The  required  format  for  input  to  the  CLIPS 
working  memory  is  CLIPS  facts.  The  formats  are  strictly  defined  in  the  procedure  through  Ada 
string  type  definition  in  accordance  with  the  data  type  defined  in  the  aforementioned  six  object 
class  managers  (16). 

Restore  Essential  Data  Model  Information,  After  each  Retrieve  procedure,  the  Restore  pro¬ 
cedure  for  the  same  object  class  accepts  as  input  a  buffer  of  facts  representing  state  information. 
These  facts  are  then  Restored  into  the  object  class  manager  by  this  procedure.  This  procedure  is 
normally  executed  as  one  of  a  sequence  of  events  in  the  initialization  of  SAtool  II  when  a  previous 
project  is  loaded  from  disk.  Thus,  the  user  could  get  all  his  work  back  into  the  Essential  Model  for 
further  rechecking  or  modification  without  having  to  retype  everything. 

The  Module  diagram  for  EssentiaLFact.Utilities  is  illustrated  in  Figure  14  (16:121). 

CLIPS^Working,.Memory  .Interface, 

This  package  provides  the  interface  from  the  Essential  Subsystem  to  the  CLIPS/ Ada  expert 
system  shell.  It  is  the  only  package  in  Satool  II  that  has  visibility  to  the  CLIPS/Ada  expert  system 
operations.  Once  all  the  Retrieve  procedures  are  completed,  they  will  be  included  in  the  interface 
package  to  be  retrieved  by  the  Fact_Buffer„Package. 

The  Module  diagram  for  Clips-.Working_MemoryJnterface  is  illustrated  in  Figure  15  (16:120). 

EssentialJO, 

This  is  a  package  that  necessary  for  the  operation  of  SAtool  II  to  .store  e.ssential  data  Tnodel  in 
a  file  and  to  load  essential  data  model  information  from  a  file  into  the  managers.  Within  the  scope 
of  this  thesis  effort,  only  the  retrieve  procedures  for  those  seven  object  classes  are  to  be  added,  facts 
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Figure  14.  Module  Diagram  for  Essential.Fact.Utilities 
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Figure  15.  Module  Diagram  for  Clip.s-VVorking-MemoryJuterface 
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Figure  16.  Module  Diagram  for  EssentiaLIO 


created  from  each  object  are  given  a  fact  name  for  for  both  the  expert  system  and  the  Essential 
Model.  For  instance,  KetrieveJCOM_Facts  in  the  EssentiaLIO  package  will  create  a  facts  file  as: 


(deffacts  icom-facts 

(icom-at tribute  Name  value  value  value) 

(  ) 


) 


The  module  diagram  for  EssentiaLIO  is  illustrated  in  Figure  16  (16:119). 


Syntax  Checking  Expert  System  Requirements 


The  IDEFo  Syntax  Expert  System  should  allow  the  user  to  check  the  hierarchical  activity 
IDEFo  syntax  and  the  boundary  IDEFo  syntax  in  any  diagrams  using  the  facts  file  created  by  the 
retrieve  procedures.  CLIPS/Ada  is  interfaced  with  the  essential  subsystem  and  has  been  proven 
to  be  effective.  A  chain  that  is  searched  or  traversed  from  the  initial  state  to  the  final  state  of 
a  problem,  during  which,  certain  types  of  solutions  are  achieved  is  called  a  forward  chain^.  That 
means  the  chaining  is  reasoning  from  facts  to  the  conclusions  which  follow  from  the  facts.  It  is  also 
known  as  data  driven,  bottom-up  reasoning(10:159“166). 

The  primary  method  of  representing  knowledge  in  CLIPS  is  a  rule.  A  rule  is  a  collection  of 
conditions  and  the  actions  to  be  taken  if  the  conditions  are  met.  The  rules  were  defined  to  describe 
how  to  solve  a  problem.  The  entire  set  of  rules  in  an  expert  system  is  called  a  knowledge  base. 
CLIPS  provides  the  search  mechanism  (  the  inference  engine)  which  select  the  facts  in  the  data 
base  to  be  matched  with  the  condition(s)  in  the  rule  base  and  continue  on  this  cycle  until  there 
is  no  rules  eligible  to  be  fired.  The  current  state  is  represented  by  a  list  of  facts.  Here  the  facts 
or  the  data  for  the  data  base  is  the  facts  retrieved  by  the  EssentiaLFact_Utilities.  The  rule  base 
is  to  be  applied  by  the  inference  engine  integrated  as  CLIPS/Ada  to  the  facts  data  file.  As  the 
LHS  of  a  rule  are  met,  the  rule  are  activated  and  placed  on  the  agenda  according  to  their  priority. 
The  priority  is  default  to  0  for  every  rule  in  the  knowledge  base,  unless  a  salience  declaration  is 
placed  ai  the  first  pattern  of  the  rule  to  change  it.  A  rule  with  the  highest  priority,  once  it  is 
activated  will  remain  at  the  top  of  the  agenda,  thus  will  be  fired  first.  After  no  rules  are  eligible  to 
be  activated,  the  top  rule  on  the  agenda  is  selected,  and  its  RHS  actions  are  executed.  As  a  result 
of  RHS  actions,  new  rules  can  be  activated  or  deactivated. 

This  pattern  matching,  activation,  firing  rules  cycle  is  repeated  until  all  rules  that  can  fire 
have  done  so  or  until  the  rule  limit  is  reached (2 1:1-5). 

*Tho  forward  chain  is  different  from  backward  chain  in  which  that  a  backward  chain  is  travel sed  from  a  hypotlicsis 
back  to  the  facts  wliich  support  tlie  hypothesis 


The  expert  system  to  be  developed  here  must  not  only  be  able  to  check  the  syntactical 
limitations  for  each  activity,  but  also  be  able  to  find  the  inconsistencies  between  hierarchical  IDEFo 
diagrams.  Thus,  provide  the  user  with  Error,  Warning,  Suggestion  or  Notice  messages.  A  summary 
of  the  functions  are  listed  below: 

•  Check  that  each  activity  must  have  at  least  one  input  and  output. 

•  Check  that  each  activity  must  have  a  name  and  be  numbered. 

•  Warning  the  user  that  any  particular  activity  has  too  many  data  element  associated  with  it, 
or  the  activity  has  some  information,  for  instance,  a  description  of  the  activity  is  missing. 

•  In  the  hierarchy  of  the  IDEFo  diagram,  each  parent  activity's  boundary  data  elements  must 
be  consistent  with  its  child  data  elements. 

•  The  number  of  icom  number  of  a  parent  diagram  and  its  child  diagrams  must  be  the  same. 

•  The  icom  code  of  a  parent  activity  should  be  consistent  with  its  child  diagram  too. 

•  The  number  of  boundary  input,  output,  control,  mechanism  consistency  check  between  a 
parent  and  its  child  activities. 

•  Utility  and  Auxiliary  rules  to  build  up  the  environment  of  the  syntax  checking  file. 

Once  the  syntax  checking  function  in  the  Essential  Model  menu  is  selected,  the  user  should  get  a 
list  of  messages  concerning  his  work.  If  an  error  was  encountered  during  the  syntax  checking,  the 
subsystem  will  be  halted  by  a  particular  rule  in  the  rules  file.  Otherwise,  a  congratulatory  message 
will  follow  all  the  Warning,  Suggestion,  or  Notice  me.ssages  if  there  are  any. 

The  CLIPS/Ada  used  the  VAX  Ada  Compiler  version  1.5  running  under  VAX-VMS  5.1.1  to 
create  the  executable.  Therefore,  it  is  useless  on  Unix  based  machines.  Since  the  primary  platform 
for  this  research  is  a  SUN-4  running  a  version  of  UNIX  and  a  Verdix  Ada  compiler,  .several  changes 
to  the  original  source  code  are  performed  by  (16).  First,  all  the  CL  PS/ A  da  .source  code  files  had 
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.ADA  or  .ADS  extensions  that  are  unacceptable  to  Verdix  were  changed  to  .a  and  jspec.a  files. 
All  the  files  was  transferred  to  Olympus  to  be  integrated  as  the  Essential  Subsystem  of  SAtool 
II.  When  compiling  CLIPS/Ada,  many  warning  messages  are  still  received.  These  messages  are 
due  to  the  source  code  authors  explicitly  declaring  loop  counters.  VAX  Ada  obviously  allows  such 
declarations;  Verdix  Ada  allows  them  also  but  does  not  particularly  care  for  them.  Therefore, 
Verdix  Ada  issues  a  warning  message(16:132-133).  Those  warning  messages  can  be  ignored.  Also, 
the  objective  of  this  study  is  to  develop  a  structured  expert  system  to  evaluate  application  facts 
and  rules  based  upon  expertise  in  the  future. 

Summary 

This  chapter  presented  the  requirements  analysis  for  the  development  of  IDEFq  Diagram 
Translator  and  IDEFq  Syntax  Expert  System.  Since  the  Essential  Subsystem  of  SAtool  II  is  entirely 
based  on  Ada  language,  the  Expert  System  will  be  done  using  CLIPS/Ada.  The  number  of  fields 
of  the  facts  format  are  unlimited,  thus  giving  us  freedom  to  define  the  format  of  our  expert  system 
checking  rule  patterns. 

All  the  facts  information  of  the  essential  subsystem  can  be  translated  into  facts  format  files, 
one  file  for  the  expert  system  and  one  for  the  essential  model.  Another  expert  system  syntax 
checking  file  can  be  loaded  with  the  facts  file  in  the  CLIPS/Ada  working  memory.  As  a  whole, 
those  files  should  be  able  to  include  all  the  information  provided  by  the  facts  file  and  provide 
necessary  error  messages  and  editing  suggestions  for  the  user  to  save  their  manual  labor  of  checking 
the  syntax  and  consistency  of  the  user’s  IDEFq  hierarchy  diagrams. 


IV,  HIGH  LEVEL  DESIGN 


Iniroduciion 

The  purpose  of  this  chapter  is  to  present  and  justify  the  preliminary  software  design  for  the 
IDEFo  Diagram  Translator  (IDT)  and  the  IDEFq  Syntax  Expert  System  (ISES).  The  idea  and 
principles  of  SADT  is  followed  throughout  the  design  process.  The  IDT  is  an  object  called  the 
"Essential  Fact  Utility”  and  is  implemented  in  the  Essential  Model.  The  ISES  is  a  CLIPS  file 
containing  all  the  knowledge  base  of  the  syntax  checking  rules.  The  IDT  is  a  set  of  Ada  procedures 
to  extract  the  data  in  Essential  Model  data  structure  and  put  this  data  into  individual  data  facts 
files.  The  emphasis  here  focuses  on  the  design  and  implementation  of  the  Syntax  Expert  System 
checking  rules.  There  are  four  stages  in  expert  system  development: 

1.  problem  selection 

2.  initial  prototype 

3.  expanded  prototype 

4.  delivery  system  (7:23) 

The  design  of  the  IDT  and  the  expert  system  are  currently  developed.  But,  the  facts  format 
resulting  from  the  IDT  is  the  data  format  of  the  expert  system.  So  the  implementation  of  the 
expert  system  heavily  depends  upon  liie  implementation  of  the  IDT. 

The  Essential  Model  of  SAtool  II  is  not  complete.  The  Syntax  Expert  System  will  be  the 
initial  prototype  of  the  expert  system  cis  a  subsystem  of  the  SAtool  II.  The  user  should  be  able  to 
create  their  hierarchical  IDEFo  diagrams*  store  and  restore  their  file  and  perform  syntax  checking 
functions  using  The  Essential  Model. 

The  underlying  efforts  for  this  thesis  investigation  include  the  development  of  the  knowledge 
for  understanding  the  background  of  SAtool  II,  the  data  structure  of  the  Es.senti^d  Model  and  the 
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application  of  knowledge  based  systems.  Since  AI  systems  do  more  than  process  data  for  the  user; 
they  use  knowledge  to  improve  their  functionality.  Expert  systems  navigate  through  knowledge 
bases  to  solve  problems  and  build  new  paths  around  rules  and  data.  Knowledge  development, 
that’s  the  real  answer(2:5). 

Previous  Study  Considerations 

The  Sun3  and  the  Sun4  workstations  using  the  SunOS  and  the  SunView  window-based  en¬ 
vironment  are  required  for  this  tool.  Also  the  IDEFq  validation  tool  is  implemented  with  Ada  in 
order  to  translate  the  essential  model  IDEFq  diagrams  into  CLIPS/ Ada  readable  facts  format.  It 
is  implemented  as  an  Ada  object  called  Essential  Fact  Utilities. 

The  expert  system  syntax  checking  functions  developed  in  (16)  has  only  validated  its  feasi¬ 
bility.  Much  more  synt^ix  checking  rules  are  to  be  implemented,  especially  for  the  consistencies  of 
boundary  arrows  between  a  parent  and  its  child  diagrams.  Once  the  two  main  objects  are  com¬ 
pleted,  they  will  be  integrated  into  the  Essential  Model  together  with  the  CLIPS/ Ada  performing 
the  syntax  checking  functions  in  SAtool  II. 

IDEFq  Diagram  Translator 

The  translator  is  used  to  translate  the  IDEFq  graphical  features  extracted  from  the  Es.sential 
Model  Object  managers  into  a  set  of  facts  formatted  for  output  to  a  file  for  permanent  storage  or 
for  input  to  the  CLIPS/Ada  working  memory  for  syntax  checking.  It  is  required  to  be  implemented 
in  Ada  language.  Ada  is  a  strongly  typed,  high  level  language  based  on  a  set  of  easily  understood 
concepts,  such  as  data  abstraction,  information  hiding,  and  strong  typing.  In  a  .sen.se,  Ada  is  a 
language  that  directly  embodies  many  modern  .software  engineering  constructs  and  is  therefore  an 
excellent  vehicle  with  which  to  express  programming  solutions  ('1.4).  The  Flow  diagram  for  the 
IDEFq  diagram  translator  is  illustrated  in  Figure  17. 
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Because  there  are  seven  Objects  Classes  and  Attributes  Based  on  the  Essential  Data  Model. 
So  there  are  seven  sets  of  Retrieve  and  Restore  procedures  for  each  of  those  seven  object  classes. 

•  ICOM  Relation  Manager 

•  Project  Manager 

•  Activity  Manager 

•  Data  Element  Manager 

•  Historical  Activity  Manager 

•  Calls  Relation  Manager 

•  Consists  Of  Relation  Manager(16) 

All  those  procedures  are  within  a  package  named  EsseniiaLFaci.UitliUes.  Through  interfacing 
with  the  object  EsseniiaUO  in  the  data  model,  each  set  of  the  facts  extracted  from  the  managers 
are  given  a  name  by  the  statement  “(deffacts  the-name-of-the-facts  (fact-1)  (fact-2).;..)”,  in  the 
package  EssentiaLIO.  Where  the  ‘deffacts’  is  a  CLIPS  construct  for  naming  a  facts  file.  Thus 
the  facts  extracted  from  the  ICOM-Relation^Manager  will  output  a  file  name  icom-relation-facts 
following  a  set  of  facts  extracted  from  the  manager  The  seven  manager  names  and  their  facts 
names  stated  by  the  EssentialJO  in  addition  to  their  facts  attributes  is  listed  in  Table  1.  This 
format  is  initiated  by  (16)  and  completed  in  this  investigation.  Notice:  those  fields  in  parenthesis 
with  capital  letters  means  a  fact  variable  to  be  extracted  from  the  managers.  To  understand  the 
meaning  of  those  attributes  and  the  value  of  fact’s  variables  should  refer  to  (16). 

If  any  variable  in  the  E.ssential  Model  is  empty,  than  the  Fact-Utility  will  input  a  “null” 
string  into  the  farts  format  If  the  fart  to  be  extrarted  is  not  empty  and  multi-field,  like  artjvity 
de.scriptions,  than  the  fi!i.  lor  E.s.sential  Model  will  save  all  the  lines  of  tlie  dc.scription  and  the  file 
for  the  CLIPS  working  memory  will  only  .save  a  ‘not- null’  for  the  .syntax  checking  expert  .system. 
The  expert  system  needs  only  to  know  that  tlic  cle.scnption  is  not  null.  Remember  that  the  facts 
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format  created  by  the  EssentiaLFact-Utility  creates  all  the  facts  input  by  the  user  for  the  IDEFo 
diagrams.  It  does  not  show  the  boundary  arrow  data  element  relations  between  any  parent  and  its 
child  activities. 

An  arrow  in  the  IDEFo  diagram  may  connect  with  functions  on  the  drawing  at  both  ends 
is  called  an  iniermediaie  arrows.  If  one  of  the  ends  may  be  unconnected,  it  represents  a  boundary 
arrow.  Boundary  arrows  indicate  that  the  information  is  produced  or  consumed  beyond  the  scope 
of  the  particular  drawing.  Boundary  arrows  at  the  A-0  level  are  referred  to  as  external  arrows  which 
represent  constraints  of  the  external  environment  and  outputs  to  that  environment.  An  important 
aspect  of  maintaining  completeness  and  consistency  in  an  IDEFo  model  is  to  make  certain  that 
all  such  boundary  arrows  match  between  a  box  and  its  lower  level  decomposition.  As  listed  in 
Table  1,  the  ICOM  codes  are  represented  as  ‘i’  for  input,  ‘c’  for  control,  ^o’  for  output  and  ‘m’  for 
mechanism  which  represents  the  ICOM  relation  of  the  data  element  arrows  to  the  activity.  They 
must  be  based  on  the  relative  positions  of  the  arrows  on  their  parent  diagram  where  they  meet  the 
edge  of  the  parent  box.  Thus  a  particular  boundary  arrow  of  a  child  diagram  should  have  the  same 
ICOM  code  as  their  parent  diagram.  Furthermore,  a  tunneled  arrow  represents  a  discontinuity 
that  a  constraint  may  arise  that  was  not  shown  on  the  parent  function  or  a  constraint  may  not 
be  appropriate  at  lower  levels  of  detail.  A  new  constraint  that  was  not  presented  on  the  higlier 
level  diagram  is  shown  as  a  boundary  arrow  with  parentheses  “(  )”  around  its  unconnected  end. 
Any  constraint  that  is  not  represented  in  a  lower  level  decomposition  is  indicated  with  parentheses 
where  the  arrow  attaches  to  the  appropriate  box. 

For  the  intermediate  arrows,  there  are  two  special  representations: 

1.  feedback  occurs  when  the  output  of  each  function  provides  cin  input  constraint  to  the  other. 

2.  iteration  occurs  when  the  output  of  each  function  provides  a  control  con.straint  to  the  othcr(20:1.3“ 
30). 
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But  the  two  special  representations  are  not  within  the  scope  of  this  thesis  research,  since 
those  are  not  implemented  in  the  Essential-Model.  The  focuses  here  is  concentrated  on  the  im¬ 
plementation  of  the  IDEFo  diagram  translator  for  the  data  elements  that  can  be  created  in  the 
EssentialJSubsystem. 

The  boundary  arrow  relationship  between  an  IDEFo  parent  diagram  and  its  child  diagrams 
will  be  created  by  the  Expert  System  Syntax  Checking  rules  before  actual  hierarchical  syntax  check¬ 
ing  took  place.  More  details  are  discussed  later  in  Chapter  6. 

Since  the  Essential  Model  developed  in  (16)  was  following  an  Object  Oriented  Design  and 
Implementation  technique,  the  Essential-Fact  .Utility  is  implemented  as  an  object  in  the  Essential 
Model,  as  defined  in  (25:14-15).  An  object  is  an  abstraction  of  a  set  of  real-world  things  such  that: 

•  all  of  the  real-world  things  in  the  set-the  instances-have  the  same  characteristics. 

♦  all  instances  are  subject  to  and  conform  to  the  same  rules. 

The  facts  format  to  be  created  is  a  set  of  real-world  things  to  be  manipulated  by  the  Syntax  Expert 
Checking  Rules  thus  a  series  of  expert  advises''  will  be  derived  for  the  user  of  the  tool. 

Retrieve  Procedures.  Because  all  the  data  of  the  IDEFo  diagrams  created  by  the  SAtool  II  user 
is  stored  as  an  Ada  record  in  the  Essential  Model,  the  Retrieve  Procedures  are  a  set  of  operations 
which  iterate  through  all  the  data  structures  of  the  Essential  Model.  The  data  structures  data 
records  will  be  Extracted  by  the  retrieve  procedures  and  put  those  data  records  into  a  specified 
facts  format  in  which  each  column  is  strictly  defined  according  to  the  data  element  data  type  in 
the  Environment  Types  of  the  Essential  Subsystem.  The  features  of  Ada  language  was  specified  in 
the  book  “Ada  as  a  second  language"  (8). 

Each  object  class  in  the  Es.senttal  Afodcl  will  have  a  set  of  facts  cxtracicd  from  the  data 
structure  and  a  given  facts  name  by  (deffacts  ....)  as  illustrated  in  Table  1.  The  facts  format  ts 
readable  to  the  CLIPS/ Ada  syntax  checking  rules.  Thus,  all  the  structures  and  data  elements  of 
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Table  1.  Object  Classes  Managers  and  Facts  Format  Extracted  by  EssentiaLFact_Utilities 


Object  Class/Manager 

facts  format  created 

ICOM  Relation 

(deffacts  icom-facts 

(icom-tuple  Activity  Data-Element  ICOM  PairJd) 
(icom-activity-inputs  Activity  .Name  #) 

(icom- activity-control  Activity -Name  #) 
(icom-activity-output  Activity-Name  #) 
(icom-activity-mechanisms  Activity JName  #)  ) 

Project 

(deffacts  project-facts 
(project-name  Project-Name) ) 

Activity 

(deffacts  activity-facts 
(act-name  Name) 

(act- numb  Name  Number) 

(act-desc  Name  Description) 

(act-has-child  Name  Child) 

(act- ref- type  Name  Reference-Type) 

(act-ref  Name  Reference) 

(act-version  Name  Activity-Version) 

(act-ver-chg  Name  New-Version) 

(act-date  Name  Date) 

(act-author  Name  Author)  ) 

Data  Element 

(deffacts  data-element-facts 
(data-element-name  Name) 

(data-element-type  Name  Data-Type) 
(data-element-minimum  Name  Minimum) 
(data-element-maximum  Name  Maximum) 
(data-element-data-range  Name  Data-Range) 
(data-element- values  Name  Values) 

(data-desc  Name  Description) 

(data-ref  Name  Reference) 

(data-ref-type  Name  Reference-Type) 

(data-ele-ver  Name  Version) 

(data-e-v-chg  Name  Version-Change) 

(data-ele-date  Name  Date) 

(data-ele-author  Name  Author)  ) 

Historical  Activity 

(deffacts  historical-activity-facts 
(historical- tuple  Project  Activity -Number)  ) 

Calls  Relation 

(deffacts  calls-relation-facts 

(calls-relation- tuple  Activity  Project  Activity-Number)  ) 

Consists  Of  Relation 

( d  effac  ts  con  sis  ts-  of-  rel  a  t  i  on  -  fa  r  ts 
(consists-of-name  ID  Parent  Child)  ) 
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ihe  users  WEFq  diagram  should  be  i  ^nded  in  the  facts  file  for  syntax  checking.  Even  if  the  user 
does  not  input  any  data  for  the  IDEFq  diagrams,  the  procedures  should  give  a  ^nulV  string  at  the 
appropriate  position  in  ihe  facts  format.  An  example  of  its  actual  output  stored  for  ihe  Essential 
Model  but  with  only  the  project  name,  one  activity,  one  data  element  is  on  the  following  page. 
Notice  Us  relation  and  difference  with  Table  1.  In  which,  Table  1  is  the  requirements  of  the  facts 
format  of  the  EssentiaLFacLUtility  that  should  be  translated  from  ihe  seven  Object  Class  Managers. 
The  name  of  each  set  of  facts  is  named  by  the  EssentialJO  with  a  (deffacts  facts-name  (fact)  (fact) 
)  statement  While  the  actual  translated  output  was  implemented  with  all  the  facts  in  between  a 
header  and  an  ending  of  the  facts  file. 

Restore  Procedures.  In  contrast  with  ihe  Retrieve  procedures,  the  Restore  procedures  are  only 
those  operations  that  iterate  through  the  facts  file  and  put  all  the  facts  back  into  the  Essential 
Model,  the  format  to  restore  each  piece  of  fact  must  be  exactly  the  same  as  they  were  as  defined  in 
ihe  previous  Retrieve  procedures,  otherwise,  an  exception  is  raised  and  the  program  stops  execution. 

IDEFo  Syntax  Expert  System  Components 

The  Inference  Engine  Selected.  The  inference  engine  of  shell  selected  for  this  thesis  research 
is  CLIPS/ Ada.  It  is  an  Ada  version  of  CLIPS,  which  stands  for  ^C  Language  Integrated  Production 
System”.  The  selection  of  shell  for  ihe  development  of  any  particular  expert  system  has  always  been 
a  kind  of  question.  “Not  a  single  existing  shell  will  satisfy  all  the  necessities  of  the  developers 
needs,”  (7:21-25). 

In  the  technical  literature  and  common  usage,  expert  system  shells  can  lie  anywhere  on 
a  continuum  fioin  inteipiett^is  of  relcitively  bin^ple  languages  to  very  elaborate  devel¬ 
opment  environments.  Each  has  its  own  purposes  and  strengths  and  can  complement 
other  shells  by  being  used  at  different  times  in  a  project’s  life  cycle. 
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;  SAtool  II  -  IDEFO  Essential  Fact  File  -  CLIPS  Readable  Format 
;  Date  and  Time  of  File  Creation  :  02/25/91  22:24:11 


; ; ♦♦START  ALL  FACTS^^ 

(defjfacts  icom-facts 

(icom-tuple  Format  ^Example  Format  _Dat  a  c 

) 

(deflacts  project-facts 
(project-name  Format  ^Example) 

) 


(deffacts  activity-facts 
(act-name  Activity_Name) 
(act-numb  Activity_Name 
(act-desc  Activity^Name 
(act-has-child  Activity^Name 
(act-ref -type  Activity^Name 
(act-ref  Activity_Name 
(act-version  Activity_Name 
(act-ver-chg  Activity_Name 
(act-date  Activity^Name 
(act-author  Activity^Name 


null) 

null) 

null) 

null) 

null) 

null) 

null) 

null) 

null) 


) 

(deffacts  data- element -facts 
(data- element -name  data_format) 
(data-element-type  data_format 
(data- element -minimum  data^format 
(data- element -maximum  data^format 
( dat  a- el ement -dat a-r ange  dat  a„f  ormat 
(data-element-values  data_format 
(data-desc  data_format 
(data-ref  data^forraat 
( dat a-r ef -type  dat a_f ormat 
(data-ele-ver  dat a_f ormat 
(data-e-v-chg  dat a_f  ormat 
(data- el e-date  dat a_f ormat 
(dat a- el e- author  dat a_f  ormat 
) 


null) 

null) 

null) 

null) 

null) 

null) 

null) 

null) 

null) 

null) 

null) 

null) 


(deffacts  historical-activity-facts 
(historical-tuple  Format^Example  AO) 

) 

(deffacts  calls-relation-facts 

(calls-relat ion-tuple  Call.Activity  Format _ Ex ample 

) 

(deffacts  consists-of -relation-facts 

(consists-of-name  1  Format^Data  formatted_data) 

) 


;  ;^+END  ALL  FACTS+^ 


All  ihe  shells  have  four  features  in  common: 

1.  ihe  minimum  feature  set  of  a  knowledge  representation  scheme 

2,  an  inference  or  search  mechanism 

5.  a  means  of  describing  a  problem 

4^  a  way  to  determine  ihe  status  of  a  problem  while  it  is  being  solved(7:21-22) 

HerCf  in  this  research,  ihe  problem  to  be  solved  is  represented  in  a  set  of  facts  lists  translated 
from  ihe  Essential  Model  Data  Structure.  Each  fact  has  limited  number  of  fields.  The  knowledge 
base  is  another  file  of  rules  that  will  be  activated  by  ihe  inference  engine,  examining,  featuring,  and 
changing  ihe  status  of  ihe  problem  until  there  is  no  rule  eligible  to  be  applied.  Thus,  a  set  of  certain 
results  IS  derived  through  ihe  process  and  expert  suggestions  is  introduced  to  ihe  user. 

Knowledge  Base.  Knowledge  base  is  ihe  heart  of  an  expert  system.  It  contains  the  problem¬ 
solving  knowledge  of  the  particular  application.  CLIPS  was  selected  as  ihe  shell  tool  for  this  thesis 
research.  The  designer  of  an  expert  system  should  have  a  full  understanding  of  both  all  ihe  appli¬ 
cation  techniques  of  a  knowledge  base  (21),  and  all  the  details  in  ihe  problem  domain.  Thus,  the 
knowledge  base  will  be  able  to  reflect  all  ihe  necessary  characteristics  intended.  In  ihe  development 
of  an  expert  system,  all  ihe  knowledge  bases  implemented  are  in  ihe  form  o/ if  ...then  rules.  A  rule 
25  a  collection  of  conditions  and  the  actions  to  be  taken  if  ihe  conditions  are  met.  The  developer  of 
an  expert  system  defines  ihe  rules  which  describe  how  to  solve  a  problem.  The  entire  set  of  rules  in 
an  expert  system  is  called  a  knowledge  base.  Some  good  examples  are  illustrated  in  (22)  about 
CLIPS  rule  developing  guides. 

The  knowledge  base  here  is  required  to  check  the  IDEF{)  syntax  features  like:  each  activity 
should  have  a  name,  number,  description,  each  activity  box  should  have  at  least  one  control  and 
one  output  arrow;  the  parent  activity  boundary  icorn  arrows  should  be  consistent  with  their  child 
activiiies  boundary  arrow.^i,  etc. 
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The  knowledge  base  must  be  able  io  derive  the  relationship  between  a  parent  diagram  and  Us 
child  diagrams.  It  cannot  check  all  the  required  features  directly  from  the  facts  created  by  the  Es- 
sentiaLFacUUtiliiy.  Hierarchical  rules  in  the  knowledge  base  to  build  up  boundary  relations  between 
any  particular  parent  and  its  child  diagrams  through  the  fact  created  are  necessary. 

If  any  syntax  inconsistencies  were  found  by  the  knowledge  base,  an  appropriate  message  should 
be  provided  to  the  user  of  the  condition  detected,  through  which,  the  user  could  easily  go  back  to 
correct  the  errors  in  his  file  without  time  consuming  and  error  pruning  manual  checks. 

As  the  IDEFo  syntax  does  suggest  that  any  parent  activity  should  not  have  more  than  six  child 
activities,  the  rules  to  be  developed  here  should  consider  those  parent  activities  with  two,  three,  four, 
five  and  six  child  activities.  But  a  set  of  rules  should  inform  the  user  that  any  any  particular  activity 
has  more  than  six  child  activities. 

Data  Base  (Working  Memory).  The  data  base  contains  a  x/road  range  of  information  about 
the  current  status  of  the  problem  being  solved.  The  temporary  output  files  of  the  IDEFo  Diagram 
Translator  became  the  initial  data  base  for  the  Syntax  Checking  ExieH  System  knowledge  base.  A 
package  named  CLIPS  Working  Mennory  Interface  in  the  Essential  Model  is  the  only  object  that  has 
direct  interface  with  the  CLIPS/ Ada.  All  the  related  files  must  through  this  interface  to  accomplish 
the  Expert  System  Syntax  Checking  funciions(I6:86). 

While  checking  the  IDEFq  syntax,  the  data  base  also  contains  a  list  of  rules  that  have  been 
examined  and  fired.  The  contents  of  the  data  base  is  volatile,  the  changing  of  its  contents  may  very 
well  affect  the  execution  of  the  knowledge  base. 

User  Interface.  The  user  interface  allows  the  user  c.o  communicate  with  the  system  and  also 
provides  the  user  tvith  an  insight  into  the  problcm-.solvtng  procc.ss  earned  out  by  the  infeTi.ncc  engine. 
The  iLScr  interface  adopted  heie  is  the  menu  selection  in  the  Essential  .Model.  The  adiantages  of 
u.stng  a  menu-based  interface  arc  as  follows: 
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1.  Users  need  not  know  the  names  of  individual  commands. 


2.  Typing  effort  is  usually  minimal. 

3.  It  is  impossible  for  users  to  put  the  system  into  an  erroneous  state. 

4.  Context-dependent  help  can  be  provided  (26: 265). 

An  example  of  ihe  program  test  and  demonsiraiion  through  the  menu  selection  user  interface  is 
in  Appendix  D.  The  input  file  ^hesis^err.esm”  is  an  output  facts  file  of  the  EssentiaLModel,  it  is 
used  to  be  restored  back  to  ihe  EssentialModel  to  check  its  IDBFo  syntax.  It  was  specially  designed 
to  project  the  syntax  checking  abilities  of  the  expert  system.  The  resulted  syntax  checking  error 
messages  are  all  commented  with  the  origin  of  their  errors.  ‘ 


Test  Plan 


A  bottom-up  testing  methodology  is  used  because  IDEFq  Diagram  Translator  and  IDEFq  Syn¬ 
tax  Expert  System  are  lower-level  than  Satool  IL  The  testing  steps  are  :  unit  testing f  integration 
testing,  and  validation  testing (26: 502),  The  Unit  testing  step  focuses  on  each  module  individually 
to  make  sure  that  its  functions  properly  as  a  unit.  Thus  theTDT  should  have  all  its  procedures 
correctly  executed  and  the  facts  file  extracted  from  the  Essential  Model  should  be  exactly  the  format 
as  defined. 


For  ihe  level  of  syntax  checking  rules,  each  group  of  rules  is  individually  tested  to  make  sure 
that  the  behavior  of  its  execution  is  under  control  and  desired  results  will  be  c*  '^aied.  Also  an  example 
project  of  hierarchical  IDEFq  diagrams  provided  in  Chapter  2  named  “Control  Elevaior'\  will  be  used 
for  validation  testing  on  the  over  all  functions  of  the  system.  Carefully  designed  errors,  including 
parent  activities  with  2,  3,  4,  5,  and  6  child  activities  are  expected  to  be  detected  by  the  Expert  System 
Rules  The  same  set  of  IDEFq  diagrams  but  with  designed  error  inputs  is  also  presented  in  contrast 
with  the  sample  IDEFq  diagrams.  Those  errors  arc  analyzed  and  explained  with  added  comments 
in  Appendix  D:  SAMPLE  ESSENTIA  I  ^^(^I)EL  IDEFq  SYNTAX  CHECKING  SCRIPT.  Each 


syntax  checking  messages  will  be  justified  to  prove  that  the  system  is  functioning  as  it  is  designed 
to  be.  Thus  we  will  be  confident  that  we  are  building  the  right  product. 

The  total  number  of  rules  for  syntax  checking  expert  system  is  198^  not  including  43  auxiliary 
rules.  A  subset  of  the  names  of  the  rules  in  the  rule  base  is  listed  below,  it  is  listed  as  an  example 
for  the  overview  of  the  rules  been  implemented.  The  complete  file  of  rules  and  their  implementation 
is  in  Appendix  C. 


1.  print-introduction 

2.  print-project-name 

3.  exit-if-error 

4.  no-error-congratulate 

5.  zero-outputs 

6.  zero-controls 

7.  too-many-mechs 

8.  too-many-outputs 

9.  too-many-controls 

10.  too-many-inputs 

11.  null-project-name 

12.  null-activity-number 

13.  null-activity-description 

14.  too-many-children-levell 

15.  too-many-children-level2 

16.  too-many-children-level3 

17.  parent-2child 

18.  parent2-boundary 

19.  child2-boundary-childl 

20.  child2-boundary-child2 

21.  clear-2child-mid 

22.  remove-2child-2boundary 

23.  rid-2child-2consists 

24.  chcck-2child-parent 

25.  check-2child-parcnt-consists 

26.  check-2chil(l-parcnt-icom 


27.  check-2child-child 

28.  parent2-icom-c 

29.  parent2-icom-o 

30.  parent2~icom“i 

31.  parent2-icom-m 

32.  parent2-control-add 

33.  parent2-output-add 

34.  parent2-input-add 

35.  parent2-mech-add 

36.  child2-icom-c 

37.  child2-icom-o 

38.  child2-icom-i 

39.  child2-icom-m 

40.  child2-control-add 

41.  child2-output-add 

42.  child2-input-add 

43.  child2-mech-add 

44.  check-parent-2child-control 

45.  check-parent-2child-output 

46.  check-parent-2child-input 

47.  check-parent-2child-mech 


Summary 

This  chapter  presenied  a  high  level  software  design  for  the  IDEFq  Diagram  Translator  and  the 
IDEFq  Syntax  Expert  System.  The  facts  format  to  be  created  by  the  translator  and  to  be  checked  by 
the  expert  system  are  described.  The  concept  of  an  Expert  System  was  explained  and  the  knowledge 
base  to  be  implemented  for  the  expert  system  in  this  research  was  analyzed  both  on  its  functional 
basis  and  on  its  structure. 

The  preliminary  test  design  expert  nitons  were  intrndnred  These  provide  a  guide  in  the  low 
level  design  in  the  next  chapter.  A  list  of  the  name  of  a  subset  of  those  rules  is  .summarized  as 
follows:  The  rules  name  listed  here  only  shows  a  parent  activity  having  two  child  activities.  For 
those  parent  activities  with  three  to  six  child  activities,  the  rules  name  arc  not  shown  here,  but 
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ihtir  names  atx  similar,  except  the  changing  of  the  number  in  those  rule  names  indicate  that  this 
rule  is  for  a  parent  activity  with  that  number  of  child  acttviiies.  Also,  more  intermediate  rules  are 
needed  for  those  rules.  The  increasing  of  child  number  increases  the  complexity  in  implementing 
those  rules. 


GO 


V.  DETAILED  DESIGN,  IMPLEMENTATION,  AND  TESTING 


Iniroduciion 

This  chapter  discusses  the  low  level  design  and  implementation  of  the  IDEFo  Diagram  Traiis- 
lator  and  the  IDEFo  Syntax  Expert  System  specified  in  the  previous  chapter.  As  mentioned  previ¬ 
ously,  the  facts  format  to  be  created  by  the  IDT  must  be  correct  before  further  effort  is  expended 
to  implement  the  syntax  checking  rules  for  the  Expert  System.  Those  facts  are  the  initial  data  beise 
(working  memory /know ledge  base)  for  the  IDEFo  Syntax  Checking  Expert  System. 

The  construct  of  syntax  checking  rules  has  been  discussed  in  chapter  4.  The  rationale  and 
detailed  implementation  of  those  rules  is  explained  in  this  chapter. 

IDEFo  Diagram  Translator  Implementation 

The  IDEFo  Diagram  Translator  is  implemented  as  an  Ada  package  named 
EssentiaLFact.Utility.  It  has  seven  pair  of  Retrieve  and  Restore  procedures.  Since  the  procedures 
for  ICOM  relations  and  Project  name  are  already  completed  in  (16),  the  remaining  work  will  have 
to  complete  the  following  procedures: 


1.  Activity: 

♦  Retrieve  Activity  Facts 

♦  Restore  Activity  Facts 

2.  Data  Element: 

♦  Retrieve  Data  Element  Facts 

♦  Restore  Data  Element  Facts 

3.  Historical  Activity: 

♦  Retrieve  Historical  Activity  facts 

♦  Restore  Historical  Activity  Facts 

4.  Calls  Relation: 
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•  Retrieve  Calls  Relation  Facts 

•  Restore  Calls  Relation  Facts 

5.  Consists  Of  Relation: 

•  Retrieve  Consists  Of  Relation  Facts 

•  Restore  Consists  Of  Relation  Facts 

The  facts  file  created  by  this  package  will  carry  a  ‘.esm’  extension.  Its  format  has  already 
shown  in  Table  1.  The  file  Essential-Fact. Utility  is  presented  in  Appendix  B. 

Its  relations  and  visibility  with  the  other  Ada  objects  in  the  Essential  Model  in  addition  to 
the  syntax  checking  rules  file  is  illustrated  in  Figure  18. 

Expert  System  Syntax  Checking  Rules  Design 

The  process  to  develop  a  rule  based  expert  system  has  many  steps: 

•  planning 

•  scheduling 

•  chronicling 

•  analysis 

•  configuration  management 

•  resource  management 

First  the  feasibility  of  this  approacii  is  demonstrated  in  (16).  A  design  goal  was  set  to  implement 
IDEFo  syntax  checking  expert  system  for  SAtool  IL  Tlie  facts  translated  to  represent  IDEFO 
diagrams  consists  of  one  or  more  fields  enclosed  in  matching  left  and  right  parentheses.  Refer  to 
Table  1. 

The  relative  position  of  each  field  in  a  fact  translated  by  IDEFo  Translator  is  strictly  defined. 
The  .space  between  cacli  field  might  be  difFerent  but  they  uill  he  neglected  by  CLIPS  if  tne  spaces  are 
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Figure  18.  Essential  Subsystems  Relations  and  Visibility 
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Figure  19.  A  Typical  Activity  Box  Features 

more  than  one.  Some  of  the  IDEFO  Diagram  syntax  can  be  directly  derived  from  the  facts  created 
by  the  IDT,  but  in  practice  most  of  them  cannot.  The  design  process  evolves  as  intermediate  rules 
are  implemented  to  create  the  data  facts  needed  to  check  particular  IDEFo  synta.  For  instance, 
the  number  of  boundary  arrows  between  a  parent  activity  and  its  child  activities.  To  be  successful, 
the  implementing  techniques  of  CLIPS  must  be  developed  through  out  this  effort .  More  efficient 
rule  sets  are  gained  from  the  experience  of  the  previous  rules  implemented.  Thus  structured  and 
related  rule  bases  are  expected  to  be  developed  in  order  to  capture  all  the  syntactical  features  of 
IDEFo  diagrams. 

IDEFo  Diagram  Syntax  Analysis.  Since  the  IDEFo  system  model  consists  of  a  series  of  hier¬ 
archically  related  function  diagrams,  each  function  box  has  to  have  some  required  syntax  features. 
Also  the  relation  between  a  parent  box  and  its  child  box  must  be  consistent  with  each  other. 

Aciiviiy  IDEFo  Syntax.  A  typical  activity  box  is  shown  is  Figure  19.  If  any  neces.sary 
features  for  a  box  is  missing,  then  its  .syntax  is  incorrect. 

The  IDEFo  syntax  for  an  activity  box  is: 
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•  An  activity  box  must  have  a  name  started  with  a  verb. 

•  An  activity  box  must  have  a  number  except  the  top-most  level  A-0  diagram. 

•  An  activity  box  must  have  at  least  one  control,  one  output  but  no  more  than  five. 

•  An  activity  box  may  have  zero  to  five  input  or  mechanism. 

•  Except  for  the  top- most  level  Context  Diagram,  there  should  no  more  than  six  boxes  in  a 
diagram. 

•  Any  arrows  or  data  connected  to  the  box  should  be  named. 

Boundary  IDEFo  Syntax.  As  mentioned  in  Chapter  4,  the  relative  positions  of  a  bound¬ 
ary  arrow  of  child  activities  must  meet  the  edge  of  its  parent  activity.  The  boundary  IDEFq  syntax 
for  a  parent  activity  and  its  child  activities  are  listed  below: 

•  A  parent  activity  must  have  at  least  two  but  no  more  than  six  child  activities. 

•  The  total  number  of  input,  output,  control,  or  mechanism  arrow(s)  of  a  parent  activity  must 
be  the  same  as  those  of  its  child  activities  boundary  input,  output,  control,  or  mechanism 
arrow(s). 

•  Each  boundary  parent  or  child  arrows  must  have  a  data  name. 

•  The  data  name  and  icom  relation  of  each  boundary  arrow  between  the  parent  and  its  child 
diagrams  should  be  consistent. 

•  Any  boundary  control  and  output  numbers  should  not  be  less  than  one  and  more  than  five. 
Unless  a  pipeline  data  item  is  used  at  the  boundary. 

•  Any  boundary  input  and  mechanism  numbers  should  not  be  more  than  five,  but  might  be  0 

At  this  point,  we  must  remember  that  the  intermediate  arrows  between  activities  will  be  the 
boundary  arrows  for  each  individual  activity.  And  should  be  the  next  lower  level  boundary  arrows 
of  the  child  activities  for  that  particular  activity  Notice  the  mid  data  element  in  Figure  20. 
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Figure  20.  Hierarchical  Boundary  Relations  Between  Parent  and  Child  Activities 
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Syntax  Checking  Environment.  Since  the  (initial-fact)  for  any  Working  Memory  always  ex¬ 
ists;  the  title  message  of  the  syntax  checking  environment  is  created  by  using  this  fact  and  with  a 
highest  salience  declaration  to  ensure  that  the  environment  will  be  created  before  any  other  mes¬ 
sages.  Right  after  this,  the  project  name  will  be  directly  derived  from  the  facts  and  presented  after 
the  syntax  checking  environment  message.  It  reads  as  follows: 


****  Essential  Subsystem  Syntax  Checking  Messages  **** 

=>  The  project  ==  Name-of- Project  ==  is  being  checked: 

After  all  the  checking  rules  were  fired,  if  no  errors  were  discovered,  than  a  congratulatory 
message  will  be  presented,  but  a  suggestion  will  also  be  presented  to  remind  the  user  recheck  the 
logical  structure  of  his  work.  Otherwise,  when  syntax  error  occurred,  another  rule  with  the  lowerest 
salience  will  be  fired  to  halt  the  program  preventing  further  rules  firing.  The  control  is  returned 
to  the  top-level  program.  This  rule  must  be  the  last  one  to  be  fired,  because  we  want  to  make 
sure  that  all  applicable  checkings  are  all  fired.  Thus  all  information  available  to  the  user  should  be 
presented  before  the  program  halted. 

Essential  Model  Fads  Formal  Analysis  for  Boundary  Ari'oxos.  Since  all  the  data  elements 
(arrows)  related  to  an  activity  are  only  represented  in  the  icom  facts. 


(icom-tuple  Activity  Data^Eleinent  ICOM  Pair  Jd) 

And  the  parent  child  relations  between  an  activity  and  its  child  activities  are  represented  in 
the  activity  facts. 


(act-has-child  Parent  .Activity  Cliildl -Activity) 
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(act-has-child  Parent -Activity  Child2-Activity) 


There  is  no  direct  trace  of  the  boundary  arrows  of  a  particular  parent  activity  and  the 
boundary  arrows  of  its  child  activities.  Thus  hierarchical  levels  of  rules  must  be  developed  before 
actual  syntax  checking  can  be  performed.  But  there  are  still  some  features  of  the  IDEFo  syntax 
that  could  be  directly  derived  from  the  facts  created  by  the  IDT. 

For  instance,  each  activity  box  must  have  at  least  one  control  and  one  output;  each  activity 
must  have  activity  number,  descriptions  and  the  project  must  have  a  project  name.  Those 
can  be  directly  derived  by  the  facts  created  by  Retrieve  and  Restore  ICOM  Relation  procedures  in 
the  IDT: 

(icom-activity-control  Activity -Name  #) 
and 

(icom-activity-output  Activity^Name  #) 

(act-name  Name) 

(act-numb  Name  Number) 

(act-desc  Neime  Description) 

(project-neone  Project^Name) 

If  any  of  those  field  are  missing,  then  the  IDT  will  put  a  ‘nuH’  in  the  appropriate  field,  thus 
the  checking  of  these  missing  fields  are  easier  to  implement.  Say  for  activity  description,  if  it  is  null 
than  the  fact  should  be: 

(act-desc  Activity -Name  null) 


If  this  fact  pattern  is  inatclied  by  the  LIIS  of  a  rule  iiainecl  '  null-activity-description’’  with 
only  this  pattern,  and  tlie  3rd  field  in  act-desc  fact  is  a  ‘nuU’,  then  the  RIIS  action  could  be  fired  : 

(defrule  null-act ivity-descript ion 
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(act-desc  ?activity-naine  null) 

=> 

WARNING:  ?activity-naine  has  no  description. 

It  must  be  mentioned  that  this  is  only  an  example  to  show  the  matching  of  a  pattern  in  the 
data  base  and  a  pattern  in  the  LHS  of  a  rule.  The  CLIPS  syntax  for  defining  a  rule  is  not  strictly 
followed  here.  Refer  to  Appendix  C  for  the  detail  implementation  of  Syntax  Checking  Rules. 

Translation  Rules  for  Boundary  Arrows,  Since  the  boundary  arrows  cannot  be  directly  de¬ 
rived  from  the  facts  created  by  IDT,  levels  of  rules  are  necessary  for  creating  those  facts  between 
each  parent  and  their  child  diagrams.  Recall  the  constraint  that  each  parent  should  have  at 
least  two  but  no  more  than  six  child  diagrams.  For  each  level  of  rules,  there  are  five  group  of  rules 
for  any  parent  activity  with  2,  3,  4,  5,  or  6  child  activities.  The  relations  between  each  parent  and 
its  child  activities  are  distinguished  by  the  parent  name  derived  from  the  facts: 

(act-has-child  Parent-Name  Childl) 

(act-has-child  Parent-Name  Child2) 

are  in  the  original  state  of  the  Essential  Model  showing  a  parent  child  relation.  Since  in 
this  example,  the  parent  activity,  Parent-Name,  has  only  two  child  activities.  A  new  parent/child 
relation  fact  should  be  created  as: 


(parent2  Parent-Name  Childl  Child2) 

This  format  of  fact  should  be  created  for  any  parent  activity  with  two  child  activities  at  any  level 
of  the  IDEFo  diagrams  with  different  Parent-Name  and  child  names. 

Different  parent  and  child  boundary  relations  should  also  be  created  for  syntax  checking. 

Those  boundary  facts  might  be  created  at  different  time  and  stored  in  different  places  in  the 
new  fact  lists  created  and  asserted  in  the  Working  Memory. 
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Figure  21.  Pattern  Matching:  Rules  and  Facts 


In  rule-based  languages,  however,  the  matching  process  takes  place  repeatedly.  Normally,  the 
fact-list  will  be  modified  during  each  cycle  of  execution.  New  facts  may  be  added  to  the  fact-list 
or  old  facts  may  be  removed  from  the  fact-list.  These  changes  may  cause  previously  unsatisfied 
patterns  to  be  satisfied  or  previously  satisfied  patterns  to  become  unsatisfied.  The  problem  of 
matching  now  becomes  an  ongoing  process.  During  each  cycle,  as  facts  are  added  and  removed, 
the  set  of  rules  that  are  satisfied  must  be  maintained  and  updated. 

It  is  the  rules  that  remain  .static  and  the  facts  that  change.  Thus,  the  facts  should  find  the 
rules(10:502-503). 

As  new  facts  are  created,  they  might  add  new  rules  eligible  to  fire  in  the  agenda,  which  is  a 
stack  of  rules  eligible  to  fire.  On  the  contrary,  as  facts  are  retracted  from  the  facts  list,  the  rules 
to  be  fired  in  the  agenda  relating  to  those  facts  will  also  be  retracted.  See  the  Pattern  Matching 
relation  of  Rules  and  Facts  in  Figure  21. 

High  Level  Creating  Boundary  Facts  Rules.  For  the  designing  of  hierarchical  rules,  care 
must  be  taken  to  make  sure  that  the  execution  of  those  rules  are  controlled.  Groups  of  rules  are 
implemented.  Thus  .some  teciiniques  or  principles  must  be  carefully  followed: 

1.  All  the  variable  names  for  each  group  of  rules  must  be  oistinct  and  easy  to  recognize 
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2.  The  ordering  of  patterns  on  the  LHS  of  a  rule  should  be  carefully  designed  in  accordance 
with  the  facts  sequence  in  the  facts  created  by  IDT  to  minimize  change  of  states  in  order  to 
improve  efficiency: 

•  most  specific  pattern  go  first 

•  patterns  matching  volatile  facts  go  last 

•  patterns  matching  the  fewest  facts  go  first 

3.  Perform  tests  as  soon  as  possible;  which  means  any  test  patterns  within  a  rule  should  be 
placed  cis  close  to  the  top  of  the  rule  as  possible. 

4.  Use  a  priority  declaration  pattern  in  a  rule  to  aid  in  controlling  the  flow  of  execution. 

5.  Use  simple  rules  vs  complex  rules;  the  key  is  to  prevent  the  unnecessary  comparisons  from 
occuring. 

6.  Reduce  comparison  by  using  temporary  facts  to  store  data(  10:502-529). 

To  create  tlr  joundary  facts  relations  between  any  parent  activity  and  its  child  activities, 
the  parent-child  relation  must  first  be  created  and  stored  in  a  single  fact.  This  is  accomplished  by 
a  set  of  rules  that  create  a  set  of  facts  each  containing  the  name  of  a  parent  activity  and  its  child 
lists  as  in  the  example  below: 

(parents  Parent-two-child  Childl  Child2) 

(parent2  Parent-of-two  Child-1  Child-2) 

(par eat 3  Parent-three-child  Childl  Child2  ChildS) 

(parent4  Parent-four-child  Childl  Child2  Child3  Child4) 

(parents  Parent-five-child  Childl  Child2  Child3  Child4  ChildS) 

(parent6  Parent-six-cbild  Childl  Child2  Child3  Child4  ChildS  ChildC) 
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With  those  facts  created  for  each  set  of  parent  and  child  activities,  the  facts  to  create  their 
boundary  relations  could  then  be  fired.  Adding  the  pattern  matching  for  icom-tuple,  each  activity’s 
name,  data,  icom  relations  might  be  created.  Using  the  parent  name  as  a  key  to  keep  track  of  any 
particular  parent*child  relations,  further  data  facts  could  be  matched  between  each  pair  of  parent 
and  child  activities  according  to  these  facts. 

For  the  child  activities,  it  is  a  little  more  complex.  Since  the  intermediate  data  arrows  are  not 
boundary  arrows.  They  must  be  cleared  to  be  consistent  with  their  parent  activity.  Many  types  of 
intermediate  arrows  are  to  be  considered  for  parents  v/ith  2,  3,  4,  5,  and  6  child  activities.  Those 
type  of  intermediate  arrows  are  to  be  retracted  from  the  created  child  boundary  facts.  Part  of  those 
types  are  illustrated  in  Figure  22  as  an  example.  The  same  or  similar  situations  my  be  extended 
to  those  different  parents  with  different  number  of  child  activities. 

For  those  intermediate  data  arrows  that  are  the  parent  or  child  data  of  a  pipeline  data  item, 
no  matter  how  many  levels  of  pipeline  data  items  may  exists.  Those  pipeline  data  relations  will  be 
stored  in  the  Essential  Model  as  consists-of-relation  facts.  Showing  that  a  parent  data  is  having  at 
least  two  child  data,  the  intermediate  pipeline  arrows  should  also  be  retracted  from  the  boundary 
fact  lists.  Two  types  of  consists  of  relation  data  arrow  forms  which  is  shown  in  Figure  23. 

Low  Level  Sifting/ Addmg  Rules,  Salience  is  suggested  not  to  be  excessively  employed 
when  patterns  can  be  used  to  express  the  criteria  for  selection(lO).  Each  level  of  rules  must  not  fire 
until  its  higher  level  rules  have  already  created  all  the  available  facts  needed  to  be  matched  for  the 
lower  level  of  rules.  Salience  is  explicitly  used  to  control  the  sequence  of  rules  execution.  Which 
means  only  after  all  the  original  boundary  facts  have  already  been  created,  then  all  the  rules  used 
to  eliminate  intermediate  arrows  will  be  fired  accordingly.  Thus  the  intermediate  arrows  will  be 
sifted  out  of  the  child  boundary  arrow  facts. 

As  an  example,  two  different  parent  but  with  the  same  number  of  three  child  diagrams  should 
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Figure  23.  Pipeline  Consists  of  Data  Arrow  Relations 

have  their  boundary  arrow  facts  created  as  follows;  the  key  to  keep  track  of  any  parent  and  its  child 
relations  is  the  parent-name  in  the  second  fields: 


(parent 3“boundary  parent-a  data-one  c) 

(parent 3~boundary  parent-a  data-two  o) 
(parent3-boundary  parent-a  data-three  i) 
(parent3-boundary  parent-a  data-four  m) 

(child3-boundary  parent-a  child-1  data-one  c) 
(child3-boundary  parent-a  child-2  data-two  o) 
(childS-boundary  parent-a  child- 1  data-three  i) 
(child3-boundciry  parent-a  child-3  data-four  m) 
2aid; 

(parent 3-boundary  parent-b  data-1  c) 
(parent3-boundary  parent-b  data-2  o) 
(parentS-boundary  parent-b  data-3  i) 

(childS-boundary  parent-b  child-one  data-1  c) 
(child3-boundary  parent-b  child-three  data-2  o) 
(childS-boundary  parent-b  child-one  data-3  i) 


Up  to  this  point,  only  after  the  boundary  facts  are  conectocl  created,  then  the  rules  to  create 
boundary  icom  numbers  could  be  correctly  fired.  The  fust  level  of  iconi  number  rules  will  create 
all  the  parent  and  child  activity  facts  witli  the  number  of  1.  For  example,  a  single  boundary  fact 
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created  as: 


(parent 3-boundary  Parent-name  P-data  c) 
(parent 3-boundary  Parent-name  data-P  c) 

Its  icom  number  fact  will  be  created  as: 


(parent3-icom  Parent -name  P-data  control  1) 

(parent3-icom  Parent-name  data-P  control  1) 

The  parent  activity  with  name  Parent-name  may  have  more  than  one  control.  The  next 
lower  level  rules  will  match  the  facts  created  and  add  them  up  to  show  the  correct  boundary  icom 
numbers  for  each  parent  and  its  child  activities.  Thus,  the  previous  two  parent3-icom  facts  will  be 
removed  from  the  facts  list,  a  new  facts  will  be  created  as: 

(parent3-icom  Parent-name  genl  control  2) 


Since  we  need  only  to  keep  track  of  the  icom  number  here,  the  data  a.ssociated  with  each 
parent  or  child  is  not  considered  here.  So  they  will  be  replaced  by  a  different  symbol  created 
by  (gensym)^  in  the  proper  field  to  make  sure  that  this  field  in  the  newly  created  facts  has  no 
duplicated  data  element  in  other  facts.  The  name  of  the  data  is  replaced  by  a  series  of  symbols  as, 
genl,  gen2,...  as  the  rule  continues  on  firing.  The  basic  reason  here  is  that  all  the  data  elements 
in  the  data  dictionary  should  have  a  different  name.  Again,  the  parents  name  is  the  key  to  keep 
track  of  the  relation  between  a  particular  parent  and  its  child  activities. 

Thus  the  final  icom  number  facts  for  a  parent  may  be  stored  in  the  facts  lists  as: 
(parent3-icom  Parent-name  P-data  control  3) 

'geiLsym  is  a  CI/IF-^S  feature  that  will  create  different  symbols  for  I  lie  matched  data  item  foi  ea<Ji  firing  of  the  ride 
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(child3-icom  Parent-name  C-data  control  3) 


Note  the  icom  number  for  parent  and  child  facts  with  the  same  parent  name  and  the  same 
icom  code,  which  is  control  here,  should  have  the  same  number  added.  Otherwise  it  is  an  IDEFo 
syntax  error. 

Hierarchical  Consistency  Checking  Rules,  Only  after  all  the  necessary  facts  for  the  boundary 
arrow  facts  between  parent  activities  and  their  child  activities  are  correctly  created.  Then  the 
consistency  checking  rules  are  ready  to  be  used. 

The  summary  of  those  if.^.-Ahen  constructs  for  certain  condition  and  appropriate  actions  are 
illustrated  in  Table  2. 

Notice  that  the  absence  of  a  particular  fact  in  the  created  fact-list  is  useful  for  the  syntax 
checking  rules.  When  a  parent  having  a  boundary  data  arrow  with  labeled  data  element  name,  but 
its  child  activities  does  not  have  the  same  boundary  data  arrow,  and  the  boundary  is  not  a  pipeline 
data,  then  it  is  a  syntax  error.  When  the  parent  and  its  child  activities  having  the  same  boundary 
data  arrow  but  with  a  different  icom  code,  it  is  still  a  syntax  error. 

Through  the  process  of  IDEFo  diagram  syntax  checking,  there  are  5  types  of  messages  that 
might  be  provided  to  the  u.ser  by  the  Syntax  Checking  Expert  System.  Tho.se  are  summarized  in 
Table  3: 

The  structure  and  visibility  between  each  set  of  rules  are  illustrated  in  Figure  24. 
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Table  2.  if..Ahen  Construct  for  the  IDEFo  Syntax  Checking  Knowledge  Base 


m 

coiidition(s) 

then 

action  (s) 

Remarks 

if 

an  activity  does 
not  have  a  name 

then 

prompt  the  user 
a  syntax  error 

The  name  should 
started  with  a  verb 

if 

an  activity  does 
not  have  a  number 

then 

prompt  the  user 
a  syntax  error 

The  number  should 
started  with  an  A 

if 

an  activity  does 
not  have  any 
description 

then 

prompt  a  warning 
about  the  situation 

A  description  is  not 
required  by  the 
syntax 

if 

an  activity  does 
not  have  any  control 

then 

prompt  the  user 
a  syntax  error 

at  least  one  control  is 
required  for  any  activity 

if 

an  activity  does 

prompt  the  user 

at  least  one  output  is 

not  have  any  output 

a  syntax  error 

required  for  any  activity 

if 

an  activity  has 
more  than  five 
input,  output, 
control  or  mechanisms 

then 

prompt  the  user 
a  syntax  error 

input  and  mechanism  may 
be  0-5  control  and 

01  tput  must  be  1-5 

if 

a  parent  activity  has  a 
boundary  data,  but  its 
child  diagrams  does 
not  have  it 

then 

prompt  the  user 
a  syntax  error 

boundary  data  element 
inconsistency  between  the 
parent  and  its  children 

if  1 

a  parent’s  boundary  data 
icom  code  is  different  than 
it’s  child’s  boundary  data 

then 

prompt  the  user 
a  syntax  error 

boundary  icom 
inconsistency  between  the 
parent  and  its  children 

if 

the  number  of  a  parent’s 
boundary  input,  output, 
control  and  mechanism  is 
different  than  its  child’s 

then 

prompt  the  user 
a  syntax  error 

number  of  boundary  data 
inconsistency  between  the 
parent  and  it’s  children 

Table  3.  Possible  Syntax  Expert  System  Checking  Results 


number 

MESSAGES 

Remarks 

1 

CONGRATULATORY: 

No  syntax  errors  was  found.  If  no 
syntax  error  facts  was  asserted  after  the 
rules  checking  is  done,  then  this  message 
will  be  presented  at  the  end  of  all  the 
other  messages. 

2 

ERRORS: 

Syntax  error  encountered,  syntax  error 
fact  will  be  asserted,  program  will  be 
halted  after  all  the  checkings  are  done. 

3 

WARNING: 

Some  features  of  the  users  project  work 
were  discovered  that  might  cause  problem. 

4 

NOTICE: 

Reminder  to  the  user  that  something  should 
be  carefully  done. 

5 

SUGGESTION: 

Suggest  the  user  that  further  manually 
recheck  might  be  helpful  to  find 
logical  errors  that  cannot  be  found  by 
the  syntax  checking  rules. 
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Figure  24.  SAtooI  11  Syntax  Checking  R  !cs  visibility  network 


The  SAtool  II  Syntax  Expert  System  Syntax  Checking  Rules  are  in  Appendix  C.  Total  of  241 
rules  are  implemented. 

IMPORTANT  NOTICE:  Because  the  behavior  of  CLIPS  control  cycles,  previously  acti¬ 
vated  rules  will  be  fired  after  those  rules  activated  later  than  it  was  activated.  If  all  the  rules  have 
the  same  priority.  The  agenda  for  the  activated  rules  is  a  first  come,  last  out  stack  operation  . 
Which  means  first  come  (rules  activated  earlier),  last  out(will  be  fired  later).  Considering  this,  the 
sequence  of  rules  presented  in  the  thesis  is  for  the  clarity  to  the  readers.  It  is  implemented  and 
grouped  using  another  sequence  in  the  Essential  Model  to  gain  efficiency  in  performing  the  Expert 
system  syntax  checking  functions. 

Testing  Expectations 

A  well  designed  testing  procedures  enables  the  software  engineer  to  derive  sets  of  input  con¬ 
ditions  that  will  fully  test  all  functional  requirements  for  a  program.  This  attempts  to  find  errors 
in  the  following  categories: 

♦  incorrect  or  missing  functions, 

♦  interface  errors, 

♦  errors  in  data  structures, 

♦  performance  errors,  and 

♦  initialization  and  termination  errors  (15:4“10). 

The  program  developed  should  be  able  to  store  all  the  user  input  IDEFo  data  structures  into  a  set 
of  facts  format  as  shown  previously,  and  the  file  could  be  restored  back  into  the  Essential  Model 
for  further  work  or  changing  or  permanent  store.  Only  when  all  the  facts  are  proven  to  be  correct, 
then  the  Expert  System  could  be  expected  to  correctly  perform  its  syntax  checking  abilities. 
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For  the  Expert  System,  a  summary  of  the  expected  performance  for  the  expert  system  are  as 
follows: 

L  Does  it  contains  all  the  required  syntactical  checking  rules  for  the  Essential  Model? 

2.  Does  it  successfully  create  all  the  boundary  arrow  facts  for  various  parent  activities  with 
different  number  of  child  diagrams  to  perform  further  hierarchical  consistency  checks? 

3.  Does  all  the  checking  rules  correctly  reflect  the  syntax  errors?  Or  does  some  of  the  rules  had 
been  wrongly  fired  and  caused  errors  thus  confused  the  user? 

Test  Results  Validation 

As  mentioned  in  the  Test  Plan  in  Chapter  4,  carefully  designed  errors  in  the  example  IDEFo 
diagrams  named  “Control  Elevator”  was  input  as  the  SAtool  II  Essential  Model  test  program.  The 
output  ^esm’  file  was  named  as  “thesis.err.esm”  to  be  used  in  the  validation  test.  In  which,  it 
includes  parent  activities  that  has  2  to  6  child  activities.  Data  inconsistencies  was  design  between 
each  pair  of  parent  and  child  activities.  Also,  icom  code  consistency,  activity  syntax,  and  number 
of  boundary  icom  consistencies  together  with  checking  the  number  of  child  activities  are  intended 
to  be  reflected  by  the  syntax  checking  expert  system. 

The  reader  of  this  thesis  should  refer  to  the  original  example  IDEFo  diagrams  in  chapter 
2,  compare  the  error  example  in  Appendix  D  and  the  syntax  checking  results  to  .see  that  the 
program  correctly  performs  its  syntax  checking  functions. 

The  results  of  the  syntax  checking  expert  system  based  on  the  “error  example”  is  summarized 
as  follows: 

♦  Activity  A2  was  found  has  more  than  6  child  activities. 

♦  Activity  A265  Send.Signals  heis  no  description. 

♦  Activity  Chec). -Destination  needs  at  least  1  control. 
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•  Data  inconsistency  between  parent  activity.  Sort-Signals  data  *o’  falsejsignals  and  its  child 
diagrams. 

•  Data  inconsistency  between  child  activity  SendJSignals  data  *o’  signals  and  its  parent. 

•  Data  inconsistency  between  child  activity  CompareJSignals  data  ‘c’  not.confirmed  and  its 
parent. 

•  Data  inconsistency  between  child  activity  Clear -Destination  data  no-stopped  and  its  parent. 

•  Data  inconsistency  between  parent  activity  Elevator-Control  data  ^o’  signals  and  its  child 
diagrams. 

•  Data  inconsistency  between  parent  activity  Elevator-Control  data  ‘c^  noJloorjsensor  and  its 
child  diagrams. 

•  icom  inconsistency  between  activity  Elevator-Control  and  its  child  diagram  Check-Destination. 

•  Data  inconsistency  between  child  activity  Sort-Signals  data  ‘o’  falsejsignals  and  its  parent. 

•  Data  inconsistency  between  child  activity  Monitor-Arrival  data  ‘c’  floorjsensor  and  its  parent. 

•  Data  inconsistency  between  parent  activity  Store-Request  data  ‘i’  passenger-requests  and  its 
child  diagrams. 

•  Data  inconsistency  between  parent  activity  Control-Elevator  data  ‘c’  floor-sensor  and  its  child 
diagrams. 

•  Data  inconsistency  between  child  activity  Elevator-Control  data  ‘c’  no-floor-sensor  and  its 
parent. 

•  there  might  be  an  ERROR:  The  number  of  boundary  controls  of  the  parent  activity  Sort-Signals 
is  1  control(s)  less  than  its  child  boundary  controls.  Are  there  “consists  oP  data  items  at 
boundary?  Please  recheck  the  syntax. 

•  there  might  be  an  ERROR:  The  number  of  boundary  inputs  of  the  parent  activity  Man- 
age.Destination  is  1  input(s)  less  than  its  child  bound 
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♦  there  might  be  an  ERROR:  The  number  of  boundary  controls  of  parent  activity  Eleva- 
torXontrol  is  1  control(s)  more  than  its  child  activities.  Are  there  ^‘consists  of”  data  items 
at  boundary?  Please  recheck  the  syntax. 

♦  there  might  be  an  ERROR:  The  number  of  boundary  inputs  of  the  parent  activity  Eleva- 
tor.Control  is  1  input(s)  less  than  its  child  boundary  inputs.  Are  there  “consists  of”  data 
items  at  boundary?  Please  recheck  the  syntax. 

♦  Data  inconsistency  between  parent  activity  Manage.Destination  data  *i*  elevatorjstatus  and 
its  child  diagrams. 

All  the  intended  syntax  errors  were  reflected  by  the  syntax  checking  expert  system.  In  compar¬ 
ison  with  the  “error  example”  IDEFo  diagrams  one  should  notice  that  a  data  inconsistency  between 
a  parent  and  child  activities  will  raise  two  error  messages.  One  by  the  “check .chikLparent”  rule 
and  one  by  “check_child_child”  rule.  The  reason  for  this  is  twofold,  one  is  to  double  check  the 
consistencies  between  each  pair  of  parent  and  child  activities,  the  other  is  for  the  lowest  level  child 
activities  that  has  a  data  arrow  inconsistent  with  its  immediate  parent  activities,  the  second  rule 
is  necessary  to  check  its  consistency  with  its  parent  activity. 

Summary 

In  this  chapter,  the  low  level  design  and  implementation  of  IDEFq  diagram  lYanslator  and 
IDEFo  Syntax  Expert  Checking  rules  are  explained.  The  component  and  levels  of  design  procc.ss 
are  illustrated  using  both  figures  and  tables.  The  expectations  for  the  testing  results  together  in 
Appendix  D  will  be  examined  to  indicate  validation  of  this  thesis  effort. 
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VI.  CONCLUSIONS  AND  RECOMMENDATIONS 


Iniroduciion 

The  purpose  of  this  thesis  investigation  is  to  continue  the  design  and  implement  an  application 
of  expert  system  for  checking  the  Essential  Model  SAtool  II  IDEFo  syntax  and  produce  an  expert 
system  structure  for  applications  using  SADT.  This  chapter  presents  a  conclusion  and  several 
recommendations  for  future  researchers. 

Conclusions 

This  investigation  is  classified  into  two  major  categories:  The  full  implementation  of  IDEFo 
Diagram  Translator  (IDT)  and  IDEFo  Syntax  Expert  System  Rules.  The  translator  for  the  IDEFo 
diagram  is  used  to  translate  the  IDEFo  graphical  features  extracted  from  the  Essential  Model 
Object  managers  into  a  set  of  facts  file.  The  fact  file  is  formatted  to  output  for  permanent  storage 
or  for  input  to  the  CLIPS/ Ada  working  memory  for  syntax  checking.  All  the  facts  are  represented 
as  a  set  of  parenthesized  lists  with  different  number  of  fields.  The  IDT  was  implemented  in  the 
Ada  language  as  a  package  in  the  Essential  Model. 

The  IDEFo  Syntax  Expert  System  consists  of  the  inference  engine,  the  knowledge  base,  the 
data  base,  and  the  user  interface.  The  expert  system  shell  selected  was  CLIPS/Ada  which  was 
already  integrated  with  the  Essential  Model  as  a  subsystem  in  (16).  The  inference  engine  search 
process  applies  the  knowledge  to  the  solution  of  a  specific  domain  using  logical  reasoning.  To  check 
IDEFo  syntax  in  any  IDEFo  hierarchical  diagrams,  the  forward  chaining  control  strategy  is  used. 
It  applies  the  knowledge  base  of  the  problem,  manipulates  the  initial  data  base,  modifies  the  data, 
and  derives  a  series  of  conclusions.  The  Expert  System  Rules  file  is  105  K  bytes,  and  the  pattern 
matching  for  the  syntax  checking  rules  is  both  memory  and  time  consuming.  Even  in  a  Mainframe, 
where  the  Essential  Model  and  all  the  related  subsystems  are,  it  takes  minutes  for  the  CLIPS/Ada 
Working  Memory  to  assert  all  the  facts  and  another  minute  for  the  CLIPS/Ada  to  compile  all  the 


84 


rules.  Then  the  Syntax  Expert  System  could  search  through  all  the  facts,  change  states,  derive 
final  syntax  expert  suggestions. 

The  Expert  System  Syntax  Checking  functions  produces  correct  checking  results  for  the 
IDEFo  diagrams  with  only  single  data  items  (constraint)  used  in  the  IDEFq  diagrams.  Pipeline 
data  item  can  be  very  complex.  A  pipeline  may  contain  several  pipelines,  and  each  single  pipeline 
inside  it  may  contain  many  data  items  or  even  pipelines.  Furthermore,  pipelines  could  be  a  branchy 
di  join  or  a  complex  combination  of  both.  It  is  almost  impossible  to  implement  CLIPS/ Ada  pattern 
matching  relations  to  check  all  the  combination  of  levels  of  those  pipeline  parent  and  child  or  even 
grand  child  pipeline  data  relation  facts,  eventhough  a  few  typical  conditions  for  pipeline  data  are 
considered  in  this  thesis  effort.  For  those  errors  detected,  the  expert  system  reminds  the  user  to 
check  if  that  kind  of  error  is  caused  by  a  pipeline  data  arrow. 

In  rule-based  languages,  the  matching  process  takes  place  repeatedly.  The  fact-list  is  modified 
during  each  cycle  of  execution.  During  each  cycle,  as  "acts  are  added  and  removed,  the  set  of  rules 
that  are  satisfied  must  be  maintained  and  updated.  Having  the  inference  engine  check  each  rule  to 
direct  the  search  for  facts  after  each  cycle  of  execution  provides  a  very  simple  and  straightforward 
technique  for  solving  this  problem.  The  primary  disadvantage  of  such  a  technique  is  that  it  can  be 
very  slow  due  to  the  property  called  temporal  redundancy.  That  is,  the  actions  of  a  rule  will 
only  change  a  few  facts  in  the  fact-list.  Hence  the  facts  in  the  expert  system  change  slowly  over 
time.  Each  cycle  of  execution  may  see  only  a  email  percentage  of  facts  either  added  or  removed 
and  so  only  a  small  percentage  of  rules  are  typically  affected  by  tiie  changes  in  the  fact-list.  Thus 
having  the  rules  drive  the  search  for  needed  facts  requires  a  lot  of  unnecessary  computation  since 
most  of  the  rules  are  likely  to  find  the  same  facts  in  the  current  cycle  as  found  in  the  last  cycle. 
Unnecessary  recomputation  could  be  avoided  by  remembering  what  has  already  matched  from  cycle 
to  cycle  and  computing  only  the  changes  necessary  for  the  newly  added  or  removed  facts  (10.502- 
504).  Unfortunately,  it  is  not  a  property  of  the  expert  system  shell,  CLIPS/Ada  (the  Ada  version 
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of  CLIPS  4.3).  The  Ada  version  of  CLIPS  4.3  is  undergoing  enhancement  by  Computer  Science 
Corporation  in  Houston,  Texas. 

All  the  facts  created  for  a  specific  hierarchical  IDEFq  diagrams  could  be  rather  a  large  list. 
It  will  take  both  time  and  memory  to  perform  the  associated  syntax  checking  functions.  So  far, 
the  test  program  has  753  facts  including  activities  that  have  2,  3,  4,  5,  and  6  child  activities.  It 
is  recommended  that,  once  the  Essential  Model,  Drawing  Model  and  the  Syntax  Checking  Expert 
System  of  SAtool  II  has  been  proven  to  be  applicable,  the  rules  of  the  expert  system  are  *fixed^ 
Then  the  compiling  of  those  rules  should  be  implemented  and  stored  before  the  user  selects  Check 
Syntax  to  gain  time  efficiency.  Up  to  this  point,  the  syntax  checking  expert  system  correctly  checks 
the  IDEFo  diagrams  syntax  with  single  data  elements.  It  also  checks  the  consistencies  of  pipeline 
data  elements  to  a  limited  extent.  The  overall  function  of  this  syntax  checking  expert  system  is 
achieved.  The  implementation  of  syntax  checking  expert  system  into  SAtool  II  is  proved  feasible. 

Recommendations 

Based  on  the  results  and  experiences  of  this  study,  this  section  presents  some  recommendations 
for  future  research  which  could  lead  to  enhance  the  capability  of  both  the  Essential  Model  and  the 
Syntax  Expert  System. 

Boundary  Single  Data  Item.  The  rules  developed  here  so  far  to  check  single  data  items 
between  parent  and  child  activities  has  been  successful.  It  is  not  likely  at  this  point  that  there  is 
a  possibility  to  simplify  the  rules  that  already  exist  as  a  result  of  this  research.  If  a  different  tool 
does,  than  it  should  be  used  in  order  to  simplify  the  rule  beise  so  it  will  be  easier  to  understand 
and  be  more  efficient. 

Boundary  Pipeline  Data  Items.  As  pipelines  could  be  a  very  complex  combination,  not  all 
features  are  included  here.  More  rules  might  be  developed  to  feature  the  intermediate  pipeline 
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data  items,  and  check  the  consistency  between  parent  activity  and  child  activities  where  levels  of 
pipeline  data  item  relations  might  exist. 

Further  IDEFo  Diagrams  Drawing  Features,  Some  features  of  the  IDEFq  diagrams  which  are 
not  included  in  the  Essential  Model  created  in  (16)  and  thus  not  considered  in  the  syntax  checking 
rules  are  also  suggested: 

•  Expand  the  functions  of  the  Essential  Model  to  include  tunnel  arrows.  Develop  rules  to  check 
the  consistency  of  those  features  of  drawing  information. 

For  instance,  since  a  tunnel  arrow  does  not  have  the  information  of  the  relationships  between 
the  attaching  activity  and  its  parent  box.  A  tunnel  arrow  attaching  an  activity  should  have 
an  ID  to  show  that  this  arrow  is  a  tunnel  arrow.  Thus  the  checking  of  consistency  should 
check  whether  a  missing  boundary  data  element  between  a  parent  and  its  child  diagrams  is  a 
tunnel,  if  it  is,  than  it  is  not  a  boundary  syntax  error. 

•  Establish  a  mechanism  either  in  Essential  Model  or  in  Drawing  Model  to  represent  squiggles, 
double  arrows  (feedback,  and  iteiou^*'.}  Expand  syntax  checking  rules  to  include  knowledge 
about  the  .specific  application  being  developed. 

•  Modify  the  menu  selection  interface  such  that  the  user  could  make  the  selection  directly  from 
the  screen  with  a  mouse. 

•  Use  compiled  rule  base  to  improve  efficiency  of  the  syntax  checking  expert  .system. 
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Appendix  A.  CLIPS  BEHAVIOR  IN  THE  BLOCKS  WORLD  PROBLEM 


In  this  example,  the  two  stack  of  blocks  is  represented  as  facts  format  in  CLIPS.  A  single 
block  may  be  stacked  upon  another  block,  the  goal  of  a  complex  blocks  world  program  would  be 
rearrange  the  stacks  of  block  into  a  goal  configuration  with  the  minimum  number  of  moves.  For 
this  purpose,  two  restrictions  are  made: 

1.  Only  one  primary  goal  is  allowed  and  this  goal  can  only  be  to  move  one  block  on  top  on 
another  block.  If  the  goal  is  to  move  block  x  on  top  of  block  y,  then  move  all  blocks  (if  any) 
on  top  of  block  x  to  the  floor  and  all  blocks  (if  any)  on  top  of  block  y  to  the  floor  and  then 
move  block  x  on  top  of  block  y. 

2.  Any  goal  must  not  have  already  been  achieved.  That  is,  the  goal  cannot  be  to  move  block  x 
on  top  of  block  y  if  block  x  is  already  on  top  of  block  y. 

Now  we  follow  the  step  by  step  method  of  building  a  program  mentioned  in  Chapter  2. 
First:  writing  pseudorules  using  English-like  text.  We  can  figure  out  that  there  are  only  four  kinds 
of  possible  conditions  needed  to  achieve  our  goal. 

1.  When  both  the  top  of  x  and  y  are  clear,  move  x  on  top  of  y  directly. 

2.  When  something  on  top  of  x,  then  move  something  on  top  of  floor  first  before  move  x  on  top 
of  y. 

3.  When  something  on  top  of  y,  then  move  something  on  top  of  floor  first  before  move  x  on  top 
of  y. 

4.  Move  something  on  top  of  floor  before  the  next  move  can  be  achieved. 

In  this  case,  x  is  considered  as  upper  block  and  y  is  considered  as  lower  block.  Then  the  pseudo 
code  can  be  written  as: 


A-1 


RULE  Move-Directly 

IF  The  goal  is  to  move  block  ?upper  on  top  oi  block  ?lower  and 
block  ?uppar  is  the  top  block  in  its  stack  and 
block  ?lower  is  the  top  block  in  its  stack, 

THEN  Move  block  ?upper  on  top  oi  block  ?lower 


RULE  Clear-Upper-Block 

IF  The  goal  is  to  move  Block  ?x  and 

block  ?x  is  not  the  top  block  in  its  stack  and 
block  ?above  is  on  top  oi  block  ?x, 

THEN  The  goal  is  to  move  block  ?above  to  the  floor 


RULE  Clear-Lower-Block 

IF  The  goal  is  to  move  another  block  on  top  of  block  ?x  and 
block  ?x  is  not  the  top  block  in  its  stack  and 
block  ?above  is  on  top  of  block  ?x, 

THEN  The  goal  is  to  move  block  ?above  to  the  floor 


RULE  Move-To-Floor 

IF  The  goal  is  to  move  block  ?upper  on  top  of  the  floor  and 
block  ?upper  is  the  top  block  in  its  stack, 

THEN  Move  block  ?upper  on  top  of  the  floor 


Second:  Based  on  the  information  given  above,  the  blocks  can  be  represented  as  stacks  of 
blocks  and  translated  into  initial  knowledge  for  the  program.  The  setting  of  the  blocks  is  illustrated 
in  Figure  n  and  its  facts  format  is  as  follows: 


(deffacts  initial-state 
(stack  a  b  c) 

(stack  d  e  f) 

(move-goal  c  on-top-of  e) 
(stack)  ) 


Finally:  The  pseuuorules  were  translated  to  CLIPS  rules  using  the  facts  as  a  guide  for 
translation. 


(defrule  move-directly 
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Floor 


Figure  A.l.  Initial  State  of  The  Blocks  World 


?goal  <-  (move-goal  ?bl  on-top-ol  ?b2) 

?stack-l  <-  (stack  ?bl  $?restl) 

?stack-2  <-  (stack  ?b2  $?rest2) 

=> 

(retract  ?goal  ?stack-l  ?stack“2) 

(assert  (stack  $?restl)) 

(assert  (stack  ?bl  ?b2  $?rest2)) 

(f printout  t  ?bl  **  moved  on  top  of  '*  ?b2  crlf)  ) 

(defrule  move-to-floor 

?goal  <-  (move-goal  ?bl  on-top-of  floor) 

?stack-l  <-  (stack  ?bl  $?rest) 

=> 

(retract  ?goal  ?stack-l) 

(assert  (stack  ?bl)) 

(assert  (stack  $?rest)) 

(f printout  t  ?bl  "  moved  on  top  of  floor.  "  crlf)  ) 


(defrule  clear-upper-block 
(move-goal  ?bl  on-top-of  ?) 

(stack  ?top  $?  ?bl  $?) 

=> 

(assert  (move-goal  ?top  on-top-of  floor))  ) 


(defrule  clear-lower- block 
(move-goal  ?  on-top-of  ?bl) 
(stack  ?top  $?  ?bl  $?) 
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=> 

(assert  (move-goal  ?top  on-top-ol  Hoot))  ) 


Now  lets  see  the  results  of  running  CLIPS  for  the  Blocks  World  program.  Any  text  after  V 
will  be  coments  added. 


CLIPS>  (load  "aiBlocks-World.clp") 
Processing  deffacts  block  initial-state 
Compiling  rule:  move-directly  +j+j+j 
Compiling  rule:  move-to-floor  +j+j 
Compiling  rule:  clear-upper-block  =j+j 
Compiling  rule:  clear-lower-block  =j+j 
CLIPS>  (facts) 

CLIPS>  (reset) 

CLIPS>  (facts) 

f -0  ( initial-fact ) 

f-1  (stack  a  b  c) 

f-2  (stack  del) 

f-3  (move-goal  c  on-top-of  e) 

f-4  (stack) 

CLIPS>  (rules) 

move-directly 

move-to-floor 

clear-upper-block 

clear-lower-block 

CLIPS>  (run) 

a  moved  on  top  of  floor, 
b  moved  on  top  of  floor, 
d  moved  on  top  of  floor, 
c  moved  on  top  of  e. 

7  rules  fired 

Run  time  is  1.5390626  seconds 

CLIPS>  (facts) 

f-0  (initial-fact) 

f-4  (stack) 

f-6  (stack  a) 

f-9  (stack  b) 

f-12  (stack  d) 

f-14  (stack  c  e  f) 

CLIPS>  (set-break  move-directly) 

CLIPS>  (set-break  move-to-floor) 

CLIPS>  (set-break  clear-upper-block) 
CLIPS>  (set-break  clear-lower-block) 
CLIPS>  (watch  all) 

CLIPS>  (reset) 

==>  f-0  (initial-fact) 

==>  f-1  (stack  a  b  c) 
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==>  1-2  (stack  del) 

==>  1-3  (move-goal  c  on-top-ol  e) 

==>  Activation  0  clear-lower-block:  1-3, 1-2 

==>  Activation  0  clear-upper-block:  1-3, 1-1 

==>  1-4  (stack) 

CLIPS>  (run) 

FIRE  1  clear-upper-block:  1-3, 1-1 
==>  1-6  (move-goal  a  on-top-ol  floor) 

==>  Activation  0  move-to-lloor:  1-5, 1-1 

Breaking  on  rule  raove-to-lloor 
1  rules  lired 

Run  time  is  0.328125  seconds 
CLIPS>  (run) 

FIRE  1  move-to-lloor:  1-5, 1-1 

<==  1-6  (move-goal  a  on-top-ol  floor) 

<==  f-1  (stack  a  b  c) 

==>  1-6  (stack  a) 

==>  1-7  (stack  b  c) 

==>  Activation  0  clear-upper-block:  f-3,1-7 

a  moved  on  top  ol  lloor. 

Breaking  on  rule  clear-upper-block 
1  rules  lired 

Run  time  is  1.8203125  seconds 
CLIPS>  (run) 

FIRE  1  clear-upper-block:  f-3,1-7 
==>  1-8  (move-goal  b  on-top-ol  floor) 

==>  Activation  0  move-to-floor;  1-8, f -7 

Bresiking  on  rule  move-to-floor 
1  rules  lired 

Run  time  is  0.3828125  seconds 
CLIPS>  (run) 


FIRE  1 

move-to-floor: 

f-8, f-7 

<==  f-8 

(move-goal  b 

on-top-of  floor) 

<==  f-7 

(stack  be) 

==>  f-9 

(stack  b) 

==>  f-10 

(stack  c) 

b  moved  on  top  of  floor. 

Breaking  on  rule  clear-lower-block 
1  rules  fired 

Run  time  is  1.59375  seconds 
CLIPS>  (run) 

FIRE  1  clear-lower-block:  f-3,f-2 
==>  f-11  (move-goal  d  on-top-of  floor) 

==>  Activation  0  move-to-floor:  f-ll,f-2 
Breaking  on  rule  move-to-floor 
1  rules  fired 

Run  time  is  0.328125  seconds 
CLIPS>  (run) 

FIRE  1  move-to-floor:  f-ll,f-2 

<==  f-11  (move-goal  d  on-top-of  floor) 

<==  f-2  (stack  d  e  f) 
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==>  1-12  (stack  d) 

==>  f“13  (stack  e  f) 

==>  Activation  0  move-directly :  f~3,f-10,f-13 
d  moved  on  top  of  floor. 

Breaking  on  rule  move-directly 
1  rules  fired 

Run  time  is  1.703125  seconds 
CLIPS>  (run) 

FIRE  1  move-directly:  f-3,f-10,f-13 
<==  f-3  (move-goal  c  on-top-of  e) 

<==  f-io  (stack  c) 

<==  f-13  (stack  e  f) 

==>  f-14  (stack  c  e  f) 

c  moved  on  top  of  e. 

1  rules  fired 

Run  time  is  0.4453125  seconds 
CLIPS>  (run) 

0  rules  fired 
CLIPS>  (facts) 
f-0  (initial-fact) 
f-4  (stack) 

f-6  (stack  a) 

f-9  (stack  b) 

f-12  (stack  d) 

f-14  (stack  c  e  f) 

CLIPS>  (agenda) 

CLIPS>  (reset) 

==>  f-0  (initial-fact) 

==>  f-1  (stack  a  b  c) 

==>  f-2  (stack  d  e  f) 

==>  f-3  (move-goal  c  on-top-of  e) 

==>  Activation  0  clesur-lower-block:  f-3, f-2 

==>  Activation  0  clear-upper-block:  f-3, f-1 

==>  f-4  (stack) 
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Appendix  B,  ESSENTIAL  FACT  UTILITIES 


—  DATE:  2/21/91 
--  VERSION:  1.0 

—  TITLE:  Essential  Subsystem  Essential^Fact.Utilities  Package 

—  FILENAME:  es^factu.a 
COORDINATOR:  Dr.  Hartrum 

—  PROJECT:  SAtool  II 

““  OPERATING  SYSTEM:  SUN  OS  Release  4.1 

—  LANGUAGE:  Verdix  Ada  Development  System  (VADS)  -  Version  6.41 

—  FILE  PROCESSING:  Must  be  compiled  after  es^genev.a,  es^proj.a, 

—  es^activ.a,  es.datel.a,  es^conof.a,  es^ICOM.a,  es^hista.a, 

—  es^calls.a 

—  CONTENTS:  Package  Essential_Fact_Utilities 

—  FUNCTIONS:  This  package  contains  two  utility  operations  for  each  of— 

—  the  7  packages  that  have  a  * manager*  in  their  names. 


SUMMARY  OF  RECENT  MODIFICATIONS: 

—  27  Oct  90:  Added  routines  to  retrieve  and  restore  the  project  name. — 

—  10  Nov  90:  Added  routines  to  retrieve  and  restore  a  portion  of  the  — 

—  Activity  Manager  information. 

—  5  Dec  90  ;  Added  routines  to  retrieve  the  Historical  Activity  Facts — 

—  7  Dec.  90  :  Added  routines  to  retrieve  the  Calls  Relation  Facts 

—  8  Dec  90  :  Added  routines  to  retrieve  the  Consists  of  Relation  Facts- 

—  8  Dec  90  :  Added  routines  to  retrieve  the  rest  portion  of  the 

Activity  Mcin<.ger  information. 

—  11  Dec  90:  Added  routines  to  retrieve  and  restore  the  data 

element  facts 

—  21  Feb  91:  All  the  Retrieve  and  Restore  procedures  tested  and 

integrated  with  the  Essential  Model, 


—  DATE:  2/21/91 

—  VERSION:  1.0 

—  PACKAGE  NAME:  **ESSENTIAL  FACT  UTILITIES** 

—  LOCATED  IN  FILE:  es_factu.a 

—  PURPOSE:  This  package  ‘.s  a  collection  of  utility  operations  that 

—  interact  with  the  managers.  Each  manager  a  2  operations  associ- 

—  ated  with  it: 


1 .  An  operation  that  retrieves  either  state  information  or 
information  destined  for  CLIPS,  based  on  a  flag  setting. 

2.  An  operation  that  accepts  state  information  as  facts  and 
restores  that  information  to  the  manager  data  structure. 

—  Warning:  The  operations  in  this  package  depend  heavily  on  the 

—  specific  column  numbers  of  the  stored  information.  An  alternative  — 
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—  to  this  methodology  is  to  develop  a  parser  to  examine  the  fact 

—  strings. 


—  PACKAGE  VISIBILITIES  REQUIRED:  Project.Manager»  Activity.Manager ,  — 

—  Data_Element».Manager,  Consists.Of^Relation^Manager,  ICOM_Relation_  — 

—  Manager,  Calls^Relation^Manager,  Historical_Activity_Manager 
--  PACKAGE  COMPOSITION:  Specification  and  Body 

—  GENERICS  INSTANTIATED:  None 

—  ADT  DESCRIPTION:  N/A  since  this  is  a  group  of  utilities. 


ORDER-OF: 

Visible:  Retrieve.ICOM.Facts  0(a  *  i) 

(  0(i)  time  when  type_facts_flag  =  true  ) 
Restore^ICOM.Facts  0(i  ♦  i) 

Retrieve^Activity^Facts  0(a  ♦  max(x,  z)) 

Restore_Activity_Facts  0(a  ♦  max(x,  a  ♦  z)  ) 

Retrieve.Pro j  ect.Facts  0(1) 

Restore. Pro ject^Facts  0(1) 

Hidden:  Padded.String  0(The_Size) 

where  i  is  the  number  of  icom  relations,  a  is  the  number  of 
activities,  x  is  the  number  of  lines  in  an  activity  description, 
and  z  is  the  number  of  children  an  activity  has 
AUTHOR(S):  Terry  Kitchen  and  Min-fuh  Su/'^ng 
HISTORY:  None  (initial  implementation) 


with  Text^IO; 

with  Activity..Class,  Activity.Manager ; 
with  Data.Element.Class ,  Project.Manager; 
with  ICOM.Relation.Class,  ICOM.Relation.Mamager ; 
with  Environment .Types; 

with  Historical.Activity.Class,  Historical.Activity.Manager ; 
with  Calls.Relation.Class ,  Calls. Relation.MEinager; 
with  Consists.Of. Relation. Class ,  Consists.Of .Relation.Manager; 
with  Data.Element. Class,  Data.Element .Manager ; 

package  Essential.Fact.Utilities  is 

—  Based  on  the  type.f acts.flag,  the  procedure  passes  a  list  of  facts 

—  to  be  stored  in  a  file  or  a  list  of  facts  to  be  placed  in  an  expert 

—  system. 

procedure  Retrieve.ICOM.Facts 
(Type.Facts.Flag  :  in  boolean; 

Fact.Manager  :  in  out  Environment .Types. Fact. Buffer.Package. Manager .Type) ; 

—  Taikes  an  input  buffer  of  ICOM  facts  and  loads  the  information  back 

—  into  the  data  structures, 
procedure  Restore. ICOM.Facts 

(The.Fact.Buff er  :  in 

Environment.Types .Fact. Buff er.Package.Manager.Type) ; 
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procedure  Retrieve_Project_Facts 
(Type^Facts.Flag  :  in  boolean; 

Fact^Manager  :  in  out  Environment ^Types. Fact _Buff er^Package. Manager^Type) ; 

—  Takes  an  input  buffer  of  project  fact(s)  and  loads  the  information  back 

—  into  the  data  structure. 

procedure  Restore_Project„Facts 
(The^Fact^Buffer  :  in 

Environment ^Types .Fact_Buf f er^Package . Manager^Type) ; 

procedure  Retrieve_Activity_Facts 
(Type_Facts_Flag  :  in  boolean; 

Fact^Manager  :  in  out  Environment^Types.Fact^Buff er^Package.Manager^Type) ; 

—  Takes  an  input  buffer  of  activity  facts  and  loads  the  information  back 

—  into  the  Activity^Manager.  It  must  be  modified  to  restore  all  the 

—  activity  facts  once  the  Retrieve_Activity_Facts  operation  is  completed, 

procedure  Restore_Activity_Facts 
{The_Fact_Buffer  :  in 

Environment .Types .Fact.Buf f er.Package . Manager.Type) ; 

—  The  project  manager  at  this  time  only  stores  a  single  name;  however, 

—  in  the  future  it  could  hold  multiple  projects. 


procedure  Retrieve.Data.Element.Facts 
(Type.Facts.Flag  ;  in  boolean; 

Fact. Manager  :  in  out 

Environment.Types .Fact.Buffer.Package .Manager .Type)  ; 


procedure  Restore.Data.Element .Facts 
(The.Fact.Buff er  :  in 

Environment.Types .Fact. Buff er.Package .Manager.Type)  ; 


procedure  Retrieve.Historical.Activity.Facts 
(Type.Facts.Flag  :  in  boolean; 

Fact.Manager  :  in  out 

Environment.Types .Fact.Buff er.Package .Manager.Type)  ; 
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procedure  Restore^Historical.Activity^Facts 
(The_Fact_Buller :  in 

Environment ^Types . Fact^Bull er^Pacltage . Manager^Type)  ; 


procedure  Retrieve^Calls^Relation^Facts 
(Type^Facts.Flag  :  in  boolean; 

Fact^Manager  :  in  out 

Environment _Types .Fact_Bulfer_Package .Manager_Type)  ; 

procedure  Restore^Calls^Relation^Facts 
(The^Fact^uller  :  in 

Environment .Types . Fact. Buff er.Package . Manager.Type)  ; 


procedure  Retrieve.Consists.Ol.Relation.Facts 
(Type.Facts.Flag  :  in  boolean; 

Fact.Memager  :  in  out 

Environment .Types . Fact.Buf f er.Package . Manager.Type )  ; 


procedure  Restore.Consists.Of .Relation.Facts 
(The.Fact.Buifer  :  in 

Environment .Types. Fact.Buf f er.Package. Manager .Type)  ; 


end  Essential.Fact.Utilities; 


package  body  Essential.Fact.Utilities  is 


—  DATE:  10/23/90 

—  VERSION:  1.0 

—  NAME:  ♦♦♦♦♦FUNCTION  PADDED  STRING^^^^^ 

—  MODULE  NUMBER:  TBD 

—  DESCRIPTION:  A  utility  function  to  pad  blanks  to  the  front  of  a 

—  of  a  string  to  reach  a  desired  size. 

—  ALGORITHM:  A  simple  if  then  else  4ith  one  embedded  loop  construct.  — 

—  PASSED  VARIABLES:  The.String,  The.Size 

—  RETURNS:  string 

—  GLOBAL  VARIABLES  USED:  None 

—  GLOBAL  VARIABLES  CHANGED:  None 
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—  FILES  READ:  Hone 

—  FILES  WRITTEN:  None 

—  HARDWARE  INPUT:  None 

—  HARDWARE  OUTPUT:  None 

—  MODULES  CALLED:  None 

—  CALLING  MODULES:  TBD 

—  ORDER-OF:  0(The_Si2e) 

—  Note  that  all  slice  operations  are  modeled  as  0(1)  time. 

—  AUTHOR(S) :  Terry  Kitchen 

—  HISTORY:  None  (Initial  Implementation) 


function  Padded_String(The_String  :  in  string  ;  The^Size  :  in  natural) 
return  string  is 
—  Loceil  Declarations  — 

Results  String:  stringd.  .The^Size) ; 

Start^Position:  natural; 
begin 

if  The.Size  <=  The^String* length  then 

Start_Position:=  The_String* length  -  The^Size  +  1; 

—  Slice  operation  is  modeled  as  0(1)  time. 

Result_String:=  The_String(Start_Position. .The^String’ length) ; 

else 

Start.Position:=  The_Size  -  The^String *  length  +  1; 
Result_String(Start„Position. .The.Size) :=  The^String; 

—  worst  case  here  -  start .position  is  (The.Size  -  2) 

—  Thus,  O(The.Size)  time  in  the  worst  case, 
for  i  in  1. .(Start.Position  -  1)  loop 

Result.String(i) :=  * 
end  loop; 
end  if; 

return  Result. String; 
end  Padded.String; 


—  DATE:  10/23/90 

—  VERSION:  1.0 

—  NAME:  ♦♦♦PROCEDURE  RETRIEVE  ICOM  FACTS^^^ 

—  MODULE  NUMBER:  TBD 

—  DESCRIPTION: 

When  the  flag  Type.Of.Facts.Flag  is  set  to  true, it  means  the  — 
client  procedure  wants  all  the  facts  that  are  necessary  for  — 
the  .esm  file.  If  the  flag  is  false,  then  the  facts  for 
the  expert  system  are  returned.  Facts  of  the  same  type  have  — 
the  same  format  no  matter  where  they  are  destined.  In  this  — 
case,  one  extra  type  of  fact  is  returned  if  the  destination  — 
is  the  an  expert  system  (icom  count  fact). 


—  icoiR  tuple  lacts:  (retrieved  when  creating  a  .esm  file  or  when 

performing  check  syntax) 

1)  a  predefined  attribute  name  (icora-tuple) 

2)  an  activity  name 

3)  a  data  element  name 

4)  an  icom  code  (i,c,o,  or  m) 

B)  and  id  number  (an  integer) 

—  icom  count  facts:  (retrieved  only  when  destination  is  CLIPS) 

1)  a  predefined  attribute  name  (e.g.,  icom^activity-inputs) 

2)  an  activity  name 

3)  an  integer  number  representing  the  input  count  e.g. 

—  ALGORITHM:  One  while  100%  extracts  the  ICOM  facts.  A  second  loop  — 

—  which  contains  an  0(i)  px-jcedure  call  is  used  to  extract  additional — 

—  facts  based  on  the  contents  of  two  different  managers. 

—  PASSED  VARIABLES:  Type^Facts^Flag,  Fact^Manager 
--  RETURNS:  None 

—  GLOBAL  VARIABLES  USED:  None 

—  GLOBAL  VARIABLES  CHANGED:  None 
--  FILES  READ:  None 

—  FILES  WRITTEN:  None 

—  HARDWARE  INPUT:  None 

—  HARDWARE  OUTPUT:  None 

—  MODULES  CALLED:  None 
~  CALLING  MODULES:  TBD 

—  ORDER-OF:  0(a  *  i)  where  ‘a*  is  the  number  of  activities  and  *i'  — 

—  is  the  number  of  tuples  in  the  ICOM  relation  manager. 

—  Note  that  all  slice  operations  are  modeled  as  0(1)  time. 

—  AUTHOR(S):  Terry  Kitchen 

—  HISTORY:  None  (Initial  Implementation) 


procedure  Retrieve^ICOM^Facts 
(Type^Facts^Flag  :  in  boolean; 

Fact^Manager  :  in  out  Environment^Types. 

Fact_Buf f er_Package . Manager_Type)  is 


—  Local  Declarations  — 

Fact. .Pointer:  Environment.Types .Fact_Buffer ..Package. Iterator.Type; 

A^Fact :  Environment _Types . Fact_String..Type ; 

Blank..Fact:  Environment^Types .Fact..String..Type:=  (others  =>  *  *); 

—  Activity  Related  Declarations  — 

Act_Nctme :  Activity^Class . Activity.Name^Type ; 

The_Act..Record :  Activity^Class . Activity.,Record_Type ; 

—  ICOM  Related  Declarations  — 

ICOM^Relation.,Record :  ICOM_Relation_Class  .  ICOM^Relat ion_Record..Type ; 
ICOM..Relation..Pointer :  ICOM„Relation_Manager  .ICOM_Relation_Pointer_Type; 
ICOM_Code:  character;  —  a  character  'i\  ’c*,  *o*,  or  ’m*. 
ICOM_Pair_Id:  natural; 

Inputs,  Outputs,  Controls,  Mechanisms  :  natural :=  0; 


begin 

—  Cleeir  the  passed  in  iact_manager. 

Environment  ^Types  .Fact^Buffer^Package  *  Clear  (Fact  ^Manager) ; 

—  Retrieve  the  state  inlonnation  from  the  tuples  regardless  of  the 

—  flag  setting. 

—  Set  pointer  to  beginning  of  raamager. 

ICOM_Relat ion.Manager . Reset_ICOM_Relat ion^Tuple^It erator ; 

—  Engage  0(i)  loop  to  extract  the  icom^tuple  facts.  The  facts 

—  extracted  will  have  the  format  discussed  above.  If  there  are 

—  no  ICOM  tuples,  this  loop  won’t  execute  and  an  empty  buffer  is  the 

—  result. 

While  not  ICOM^Relation^Manager .ICOM.Relation^Tuple^Iterator.Done  loop 

—  Get  a  record. 

ICOM^Relation_Record:=  ICOM^Relation.Manager, 

Value„Of_ICOM_Relation_Tuple„At_Iterator; 

—  Place  the  record  into  a  fact  string  at  specific  positions. 

—  Initialize  the  fact  string  to  all  blanks  first, 

—  All  string  assignments  are  modeled  as  0(1), 

A_Fact:=  Blaink^Fact; 

A_Fact(l,  .10)  :=  "icom-tuple'* ; 

A_Fact(ll) 

A_Fact(12. .36)  :=  ICOM_Relation_Record, Activity; 

A„Fact(37) 

A_Fact(38. .62)  :=  ICOM„Relation_Record.Data.Element ; 

A«Fact(63) 

A_Fact(64)  :=  ICOM.Relation^Record. Relationship; 

A«Fact(65) 

A.Fact(66. .71)  := 

Padded_String(integer ’iraage(ICOM^Relation_Record,Pair^Id) ,  6) ; 

—  Store  this  fact  in  the  fact  buffer. 

Environment _Types . Fact_Buff er.Package . Add^Item 

(A.Fact,  Fact^Manager ,  Fact. Pointer) ; 

—  Advance  pointer  to  next  ICOM  tuple  in  manager. 
ICOM.Relation.Manager . Advance.Iterator.To.Next.ICOM.Reiat ion.Tuple ; 
end  loop; 

—  Facts  for  expert  system  only. 

—  Perform  check  here  to  determine  if  ICOM  counts  are  requested, 
if  Type.Facts.Flag  =  False  then 

—  For  each  activity,  need  to  determine  the  number  of  inputs,  outputs, 

—  controls  and  mechanisms.  So,  engage  loop  to  get  an 

—  activity  name  then  use  the  name  to  determine  the  ICOM  counts. 

—  Loop  executes  a  times  with  an  0(i)  procedure  call.  Thus,  the 

—  order-of  is  0(a  *  i). 

Act ivity.Manager. Res et.Activity.lt erator; 
while  not  Activity.Manager. Activity.Iterator.Done  loop 
—  Get  cin  activity  record  that  contains  a  name. 

The.Act. Record : =  Activity.Manager . Value.Of. Activity. At.Iterator ; 
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—  0(i)  procedure  to  count  the  ‘‘arrows'*  for  this  activity. 

—  Note:  if  the  ICOM  mgr  is  empty,  this  procedure  returns  all 

—  zeroes  and  does  not  examine  the  activity  name. 

ICOM.Relat ion^Manager , Value_Of .ICOM.Counts 

(The.Act^ecord.Name,  Inputs,  Controls,  Outputs,  Mechainisms ) ; 

—  Now  must  add  the  facts,  (a  better  block  of  code  is  possible  here) 

—  Place  the  record  into  a  fact  string  at  specific  positions. 

—  Initialize  the  fact  string  to  all  blanks  first. 

—  All  string  assignments  are  modeled  as  0(1). 

—  Add  fact  for  number  of  inputs. 

A^Fact:=  Blank.Fact; 

—  The  padding  of  blanks  in  the  first  field  is  for  aesthetic 

—  purposes  only, 

A_Fact(l.  .24)  :=  "icom-activity-inputs 

A^Fact(25)  :=  »  *; 

A_Fact(26. .50)  :=  The_Act_Record. Name; 

A.Fact(51)  1=  ' 

A_Fact(52. .57)  :=  Padded„String(integer 'image(Inputs) ,  6); 

--  Store  this  fact  in  the  fact  buffer,  0(1)  time. 

Environment _Types . Fact.Buffer .Package , Add.Item 
(A.Fact,  Fact .Manager ,  Fact.Pointer) ; 

--  Add  fact  for  number  of  controls.  0(1)  time. 

A.Fact:=  Blank.Fact; 

A.Factd . .24)  :=  "icom-activity-controls 

A_Fact(25) 

A.Fact(26. .50)  :=  The. Act.Record. Name; 

A.Fact(51)  :=  * 

A.Fact(52.  .57)  ;=  Paddi:^  ^String  (integer 'image  (Controls ) ,  6); 

—  Store  this  fact  in  the  fact  buffer. 

Environment .Types . Fact.Buf f er.Package . Add.Item 

(A. Fact,  Fact.Manager ,  Fact.Pointer); 

—  Add  fact  for  number  of  outputs.  0(1)  time. 

A.Fact:=  Blank.Fact; 

A.Fact(l. .24)  :=  "icom-activity-outputs  "; 

A.Fact(25) 

A.Fact(26 . . 50)  :=  The. Act. Record .Name; 

A.Fact(51) 

A.Fact(52. .57)  :=  Padded. String(integer 'image(Outputs) ,  6); 

—  Store  this  fact  in  the  fact  buffer. 

Environment .Types .Fact. Buff er.Package. Add.Item 

(A. Fact,  Fact.Manager,  Fact.Pointer); 

—  Add  fact  for  number  of  mechanisms.  0(1)  time. 

A.Fact:=  Blank.Fact; 

A.Fact (1 . . 24)  ;=  "icom-activity-mechanisms" ; 

A.Fact(25) 

A.Fact (26 .. 50)  :=  The. Act. Record. Name; 

A.Fact(51) 


A_Fact(62. .57)  :=  Padded.String (integer ’ image(Mechanisms) ,  6); 
—  Store  this  fact  in  the  fact  buffer, 

Enviroiunent slypes , Fact.Buf f er.Package , Add^Itera 
(A^Fact,  Fact^Manager,  Fact^Pointer) ; 

—  Advance  Activity^Manger  iterator  to  next  activity  record. 
Activity^Manager. Advance_Iterator_To_Next_Activity; 
end  loop; 
end  if; 

end  Retrieve.ICOM^Facts; 


—  DATE:  10/02/90 

—  VERSION:  1.0 

—  -  NAME:  ♦♦♦PROCEDURE  RESTORE  ICOM  FACTS^^^ 

—  MODULE  NUMBER:  TBD 

—  DESCRIPTION:  Restores  the  icom  facts  into  the  ICOM  Relation  Manager — 

—  ALGORITHM:  A  single  while  loop  controls  the  execution  with  aoi 

—  embedded  call  to  an  0(i)  procedure. 

—  PASSED  VARIABLES:  The^Fact.Buff er  (contains  the  icom  facts) 

RETURNS:  None 

—  GLOBAL  VARIABLES  USED:  None 

—  GLOBAL  VARIABLES  CHANGED:  None 

—  FILES  READ:  None 

—  FILES  WRITTEN:  None 

—  HARDWARE  INPUT:  None 

—  HARDWARE  OUTPUT:  None 

—  MODULES  CALLED:  None 

—  CALLING  MODULES:  TBD 

—  ORDER-OF:  0(i  ♦  i)  where  i  is  the  number  of  facts  in  the  fact 

—  buffer  which  should  be  the  same  as  the  no.  of  ICOM  tuples;  the 

—  of  ICOM  tuples  is  represented  by  an  ^i*. 

—  Note  that  all  string  slice  operations  are  modeled  as  0(1)  time. 

““  AUTHOR(S):  Terry  Kitchen 

—  HISTORY:  None  (Initial  Implementation) 


procedure  Restore^ICOM.Facts 
(The.Fact^Buff er  :  in 

Environment .Types .Fact.Buff er.Package.Manager.Type)  is 
—  Local  Declarations  — 

Fact.Pointer :  Environment . Types .Fact_Buffer.Package. Iterator .Type; 
A.Fact :  Environment .Types . Fact.String.Type ; 

First. Char:  natural :=  0; 

Char.Position:  natural :=  0; 

Temp.Pos:  natural :=  0; 

—  ICOM  Related  Declarations  — 

ICOM.Relation.Record :  ICOM.Relation.Class . ICOM.Relation.Record.Type ; 
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ICOM^Relation^Pointer:  ICOM^Relation^Manager.ICOM.Relation^Pointer.Type; 
Kull_IC0M3«cord :  ICOM^Relat ion^Class  *  ICOM^elat ion.Record^Type ; 

begin 

"  Check  lor  empty  buffer  of  facts.  If  empty,  do  nothing, 
if  Environment ^Types . Fact^Buf f er^Package , Is.Empty (The^Fact^Buf f er )  then 
return; 
end  if; 

—  Initialize  iterator  to  first  tuple/fact. 

Environment .Types. Fact^Buffer^Package.Initialize.Iterator 

(Fact.Pointer,  The.Fact.Buffer) ; 

—  Engage  loop  to  extract  the  icom.tuple  facts  from  a  buffer 

—  one  at  a  time.  This  loop  is  0(i)  time. 

While  not  Environment .Types. Fact.Buffer.Package.Is.Done (Fact .Pointer)  loop 

—  Get  a  record. 

A.Fact : =  Environment .Types . Fact.Buf f er.Package . Value.Of .Item 
(Fact .Pointer) ; 

—  Since  we  put  the  information  in  the  string,  we  know  the 

—  exact  columns  where  information  should  be. 

—  All  string  assignments  are  modeled  as  0(1); 

—  Insure  the  fields  are  all  blanks. 

ICOM.Relat ion.Record : =  Null.ICOM.Recora ; 

—  Retrieve  the  fields  from  the  fact  string. 
ICOM.Relation.Record.Activity:=  A.Fact(12. .36) ; 

ICOM.Relat ion.Record. Data.Element:=  A.Fact(38. .62); 
ICOM.Relation.Record.Relationship:=  A.Fact(64) ; 

ICOM.Relat ion.Record. Pair.Id:=  integer ’value (A.Fact (66. .71)); 

—  Load  this  fact  back  into  the  ICOM  mamager.  0(i)  procedure  call. 
ICOM.Relation.Manager .Create.ICOM.Relation.Tuple 

(ICOM.Relat ion.Record,  ICOM.Relation.Pointer) ; 

—  Advaoice  pointer  to  next  ICOM  tuple  in  manager. 

Environment.Types .Fact.Buf f er.Package .Get.Next(Fact.Pointer) ; 

end  loop; 

end  Restore. ICOM.Facts; 


—  DATE:  10/27/90 

—  VERSION;  1.0 

—  NAME:  ♦♦♦PROCEDURE  RETRIEVE  PROJECT  FACTS++^ 

—  MODULE  NUMBER:  TBD 

—  DESCRIPTION: 

When  the  flag  Type_Of.Facts.Flag  is  set  to  true, it  means  the  — 
client  procedure  wants  all  the  facts  that  are  necessary  for  — 
the  .esm  file.  If  the  flag  is  false,  then  the  facts  for 
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the  expert  system  are  returned.  Facts  of  the  same  type  have  — 
the  same  lormat  no  matter  where  they  are  destined.  In  this  — 

—  case,  the  project  name  is  but  a  single  fact.  Future 

—  modifications  to  SAtool  II  could  include  more  information  in  — 
the  Project^Manager  however,  thus  this  procedure  is  of  use.  — 

—  icom  tuple  facts:  (retrieved  when  creating  a  .esm  file  or  when 

performing  check  syntax) 

1)  a  predefined  attribute  name  (project-name) 

2)  the  project  name  (if  the  name  is  null,  the  word  *null^  is 
placed  in  the  field. 

—  ALGORITHM:  All  simple  0(1)  statements  and  2  0(1)  procedure  calls.  — 

—  PASSED  VARIABLES:  Type^Facts.Flag,  Fact.Manager 

—  RETURNS:  None 

—  GLOBAL  VARIABLES  USED:  None 

—  GLOBAL  VARIABLES  CHANGED:  None 

—  FILES  READ:  None 

—  FILES  WRITTEN:  None 

—  HARDWARE  INPUT:  None 

—  HARDWARE  OUTPUT:  None 

—  MODULES  CALLED:  None 

—  CALLING  MODULES:  TBD 

—  ORDER-OF:  0(1) 

—  AUTHOR(S):  Terry  Kitchen 

—  HISTORY:  None  (Initial  Implementation) 


procedure  Retrieve„Project_Facts 
(Type^Facts^Flag  :  in  boolean; 

Fact^Manager  ;  in  out  Environment^Types. 

Fact^Buf f er^Package . Manager_Type)  is 


—  Local  Declarations  — 

Fact^Pointer :  Environment _Types .Fact_Buffer_Package. Iterator_Type; 
A.Fact :  Environment _Types . Fact_String_Type ; 

Blank.Fact:  Environs. mt^Types. Fact _String.Type:=  (others  =>  ’  *); 

—  Project  Related  Declarations  — 

Pro j  ect.Name :  Environment ^Types . Pro j  ect.Narae^Type ; 

begin 

—  Clear  the  passed  in  fact_manager . 

Environment .Types . Fact.Buf f er.Package . Clear (Fact.Kanager) ; 

—  For  the  Project  Manager,  the  same  information  is  returned 

—  regardless  of  the  flag  setting.  The  parameters  are  still  used 

—  however  in  case  future  modifications  will  need  them. 

Pro j  ect.Name : =  Pro j  ect.Manager . Value.Of .Pro j  ect.Naime ; 

—  Check  for  blank  name.  If  it*s  blank,  give  it  the  name  ‘null*. 

—  The  then  part  should  never  execute  i^  SAtool  II  forces  the  user 

—  to  always  assign  a  name  to  a  project. 

if  Project.Name  =  Environment.Types .Null.Project.Name  then 
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Project_Naine:=  ’'null 
end  if; 

—  Create  the  fact.  All  0(1)  time. 

A_Fact:=  Blank.Fact; 

A.Fact  ( 1 . .  12) :  =  ’’pro j ect-narae" ; 

A^Fact(13):=  ’  »; 

A_Fact(14. .38) :=  Project^Name; 

—  Store  this  fact  in  the  fact  buffer.  Just  one  fact.  No  loop. 

—  0(1)  time. 

Environment  ^Types .  Fact^Buf  f  er^Package .  Add^It  em 
(A_Fact,  Fact^Manager,  Fact_Pointer) : 

end  Retrieve^Project^Facts; 


“  DATE:  10/27/90 
“  VERSION:  1.0 

NAME:  ♦♦♦PROCEDURE  RESTORE  PROJECT  FACTS^+^ 

—  MODULE  NUMBER:  TBD 

—  DESCRIPTION: 

—  ALGORITHM:  All  0(1)  statements  and  procedure  calls. 

—  PASSED  VARIABLES:  The^Fact^Buff er  (contains  the  project  fact) 
--  RETURNS:  None 

“  GLOBAL  VARIABLES  USED:  None 

—  GLOBAL  VARIABLES  CHANGED:  None 

—  FILES  READ:  None 

—  FILES  WRITTEN:  None 

—  HARDWARE  IJPUT:  None 

—  HARDWARE  OUTPUT:  None 
MODULES  CALLED:  1  one 

~  CALLING  MODULES:  TBD 

—  ORDER-OF:  0(1) 

—  Note  that  all  string  slice  operations  are  modeled  as  0(1)  time. 
~  AUTHOR(S) :  Terry  Kitchen 

—  HISTORY:  None  (Initial  Implementation) 


procedure  Res t or e.Project .Facts 
(The.Fact.Buffer  :  in 

Environment .Types .Fact .Buff er. Package . Manager. Type)  is 

—  Local  Declarations  — 

Fact .Pointer :  Environment .Types .Fact.Buffer.Package. Iterator .Type; 
A.Fact :  Environment .Types . Fact.String.Type ; 
first.Char:  natural :=  0; 

—  Project  Related  Declarations  — 

Pr 0 j  ect.Name :  Environment. Types . Pro j ect.Name.Type ; 

begin 

—  Check  for  empty  buffer  of  facts.  If  empty,  do  nothing. 
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if  Environment .Types .Fact _Buller_Package.Is_Empty(The_Fact_Buifer)  then 
return; 
end  if; 

—  Initialize  iterator  to  first  tuple/fact. 

Environment .Types .Fact.Buffer.Package . Initialize.Iterator 

(Fact . Pointer ,  The.Fact.Buffer) ; 

—  Get  a  record.  There  is  only  one  fact!  0(1)  call. 

A.Fact : =  Environment .Types . Fact.Buf f er.Package . Value.Of .Item 

(Fact .Pointer) ; 

—  We  know  that  the  project  name  starts  in  column  14  at  this  point. 
First.Char:=  14; 

—  Since  there  is  only  one  field  of  data,  no  looping  is  necessary. 

—  The  remaining  characters  after  the  project  name  are  blank. 
Project.Name:=  A.Fact (First.Char. .38); 

—  Need  to  check  if  the  project  name  was  null. 

—  If  the  name  is  null,  we  do  nothing,  since  the  Project.Manager 

—  initializes  the  project  name  to  all  blanks  anyway, 
if  Project  .Named.  .4)  =  ‘'null"  then 

null; 

else 

—  Load  the  project  name  back  into  the  manager. 

Pro j  ect.Manager . Set.Pro j  ect.Name (Pro j  ect.Name ) ; 
end  if; 

end  Restore.Project.Facts;' 


—  DATE:  2/19/91 

—  VERSION:  1.0 

NAME:  ***PR0CEDURE  RETRIEVE  ACTIVITY  FACTS*** 

—  MODULE  NUMBER:  TBD 

—  DESCRIPTION: 

When  the  flag  Type.Of.Facts.Flag  is  set  to  true, it  means  the  — 
client  procedure  waoits  all  the  facts  that  are  necessary  for  — 
the  .esm  file.  If  the  flag  is  false,  then  the  facts  for 
the  expert  system  are  returned. 

—  Note  that  this  procedure  only  handles  a  subset  of  the  activity 

—  facts:  the  activity  name,  number,  and  description.  The  remaining  — 

—  facts  must  still  be  retrieved! 

—  Activity  facts  format  for  .esm  file: 

—  Note  that  if  an  activity  naane  exists,  then  the  other  fields 

—  will  be  filled  with  a  string  called  **null**  if  they  are  empty. 

(act-name  ‘‘activity  name**) 

(act-numb  ‘‘activity  name**  ‘‘activity  number**) 

(act-desc  ‘ ‘activity  name* *  ‘‘wordl**  ‘*word2**  etc.) 


B-13 


—  The  last  fact  is  repeated  for  each  line  of  the  description. 

—  Activity  facts  format  for  CLIPS: 

—  Kote  that  CLIPS  does  NOT  need  to  check  the  description.:  Therefore, — 

—  just  pass  it  a  fact  with  **null**  or  ‘ 'not-null^ *  to  save  space  in  — 

—  the  working  memory. 

(act-name  ‘‘activity  name’O 

(act-numb  ‘ ‘activity  name' *  ‘ ‘activity  number *' ) 

(act-desc  ‘ ‘activity  name' '  ‘ ‘not-null' ') 

—  As  with  the  facts  for  the  .esm  file,  if  any  of  the  fields  are  empty — 

—  the  word  “null''  is  inserted  instead. 

—  ALGORITHM:  One  outer  loop  that  iterates  through  the  activities 

—  contains  simple  if  then  else  constructs  and  one  inner  loop.  These  — 

—  mechanisms  contain  s»-vcxal  0(1)  function  calls  to  the  activity 

—  manager  to  retrieve  information. 

—  PASSED  VARIABLES:.  Type_Facts_Flag,  Fact_Manager 

—  RETURNS:  None 

—  GLOBAL  VARIABLES  USED:  None 

—  GLOBAL  VARIABLES  CHANGED:  None 

—  FILES  READ:  None 

—  FILES  WRITTEN:  None 

—  HARDWARE  INPUT:  None 

—  HARDWARE  OUTPUT:  None 

—  MODULES  CALLED:  Several  Activity  Mcinager  procedures  and  functions,  — 

—  plus  some  Text„Buff er_Package  operations.^ 

—  CALLING  MODULES:  Essential„IO.Save„Project,  Clips_Working„Memory_  — 

—  Interface .Assert _All_Facts 

—  ORDER-OF:  0(a*  max(x,2)  where  a  =  #  activities,  and  x  is 

—  the  number  of  lines  in  a  description,  and  z  =  #  of  activ  children.  — 

—  Note  that  all  slice  operations  are  modeled  as  0(1)  time. 

—  AUTHOR(S):  Terry  Kitchen  and  Min-fuh  Shyong 

—  HISTORY:.  None  (Initial  Implementation) 


procedure  Retrieve_Activity_Facts 
(Type_Facts_Flag  :  in  boolean; 

Fact^Manager  in  out  Environment_Types . 

Fact^Buf f er_Package .  Mainager^Type)  is 


—  Local  Declarations  — 


Fact_Pointer :  Environment _Types . Fact_Buf f er_Package . Iterator^Type ; 
A..Fact :  Environment ^Types .  Fact_String..Type  ; 

Blank^Fact:'  Environment _Types .Fact_String_Type:=  (others  =>  '  '); 
—  Activity  Related  Decl^^rations  — 


Act^Name 

The^Act^Record 


:  Activity^Class .  Activity^Name..Type ; 

:  Activity^Class . Activity_Record^Type; 


The_Iterator 

Child.Iterator 


:  Environment _Types .  Text^Buf  f  er.„Package .  Iterator^Type 
:  Environment^Types  .  Data^Buf  f  er^Package .  Iterator ^Type 
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A Jescription^Line  :  Enviromront .Types. DD_Text_Type; 

A.Child  :  Environment .Types . DD.?’ eld.Type ; 

—  Added  new  facts  120390 

Ref  erence.lt erator  :  Envir onment. Types  .Text. Buff  er.Package .  Iterator.Type ; 
A.Reference.Line  :  Environment  .Types.  DD.Text  .Type; 

—  Added  new  Vars  fcr  version  changes  *** 

Version.lt erator  :  Environment.Types.Text.Buff er.Package. Iterator.Type; 

Version.Line  :  Environment  .Types.  DD.Text  .Type; 


begin 

—  Clear  the  passed  in  fact.manager .  0(1)  time. 

Environment .Types . Fact.Buff er.Package . Clear (Fact .Manager) ; 

—  Set  pointer  to  beginning  of  manager.  0(1)  time. 

Act  ivity.Meinager  .Reset.Activity.lt  erator ; 

—  Engage  loop  to  extract  the  facts  associated  with  an  activity.  The 

—  facts  extracted  will  have  the  format  discussed  above.  If  there  are 

—  no  activities,  this  loop  won't  execute  and  an  empty  buffer  is  the 

—  result. 

—  This  loop  runs  a  times  where  a  is  the  number  of  activities.  At  this 

—  time  there  is  only  one  inner  loop  of  0(x)  time.  Thus,  the  time 

—  complexity  is  0(a  +  x) . 

while  not  Act ivity. Manager. Activity. I ter at or.Done  loop 

—  Get  a  record.  0(1)  time. 

The.Act.Record:=  Activity.Manager. 

Value.Of .Activity.At.Iterator ; 

—  Regardless  of  the  Type.Facts.Flag  setting,  the  activity  name  is 

—  always  added  to  the  fact  buffer. 

—  Place  the  activity  naone  into  a  fact  string  at  specific  positions. 

—  Initialize  the  fact  string  to  all  blanks  first. 

—  All  string  assignments  are  modeled  as  0(1). 

—  ♦★♦♦Create  Activity  Name  Fact^^^^ 

A.Fact:=  Blank.Fact; 

A.Fact(1..8)  :=  “act-name'* ; 

A.Fact(9) 

A.FactdO.  .34)  :=  The ^Act.Record. Name; 

—  Store  this  fact  in  the  fact  buffer.  0(1)  time. 

Environment .Types . Fact.Buff  er.Package . Add.Item 

(A.Fact,  Fact .Manager,  Fact.Pointer) ; 

—  ♦♦♦♦Create  Activity  Number  Fact^*** 
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A_Fact:=  Blank.Fact; 

A.Fact(1..8)  :=  "act-numb'*; 

A_Fact(9)  :=  »  »; 

A^FactdO.  .34)  ;=  The^Act .Record. Name; 

A.Fact(35) 

—  This  ii  then  construct  determines  what  goes  into  the  last  field. 

—  If  the  activity  number  is  not  null  then  create  a  fact  with  the 

—  activity  number  in  it.  Flag  setting  doesn^t  matter  here. 

if  The.Act .Record. Number  /=  Activity.Class .Null.Activity.Number  then 

—  All  statements  modeled  as  0(1)  time. 

A.Fact(36. .55)  :=  The_Act_Record.Number ; 

else 

—  The  activity  number  is  null,  so  create  a  null  fact  for 

—  either  the  .esm  file  or  the  expert  system.  Again,  the  flag 

—  setting  does  not  matter.  All  0(1)  time. 

A.Fact(36. .39)  :=  "null"; 

end  if; 

—  Store  this  fact  in  the  fact  buffer.  0(1)  time. 

Environment .Types . Fact.Buf f er.Package . Add. Item 

(A.Fact,  Fact.Manager,  Fact .Pointer) ; 

—  ♦♦♦♦Create  one  or  more  Activity  Description  Facts^^^^ 

—  If  the  activity  description  is  null  then  only  a  single  fact  is 

—  created  regeirdless  of  the  flag  setting. 

if  Environment .Types .Text. Buff er.Package . Is.Empty 
(The. Act.Record. Descript ion)  then 

—  Create  a  null  fact, 

A.Fact :=  Blank.Fact; 

A_Fact(1..8)  :=  "act-desc"; 

A.Fact (9) 

A.Fact (10. .34)  :=  The.Act.Record . Name ; 

A.Fact(35)  ^ 

A.Fact (36. .39):=  "null"; 

—  Store  this  fact  in  the  fact  buffer.  0(1)  time. 
Environment.Types. Fact. Buff er.Package. Add.Item 
(A.Fact,  Fact.Manager,  Fact . Pointer ) ; 

—  A  false  flag  setting  means  the  fact  is  for  the  expert  system. 

—  For  a  description,  we  don't  want  the  whole  description  in  the 

—  working  memory,  so  just  store  a  "not-null"  string! 
elsif  Type.Facts.Flag  =  False  then 

—  Create  a  fact  that  shows  the  description  is  not  null. 

A.Fact  ;=  Bleink.Fact; 

A.Fact(1..8)  :=  "act-desc"; 

A.Fact(9)  :=  '  '; 

A.Fact(10. .34)  :=  The. Act. Record. Name; 
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A.Fact(35)  ^  ^ 

A_Fact(36,  .43)  :=  *'not-null*’ ; 

—  Store  this  fact  in  the  fact  buffer.  0(1)  time. 
Environment .Types . Fact .Buffer .Package . Add.It em 
( A.Fac t ,  Fact .Manager ,  Fac t .Po int  er ) ; 


else 

—  At  this  point  we  know  the  flag  is  true  which  means  the  fact 

—  is  to  go  to  the  .esra  file.  However,  there  may  be  multiple  lines 

—  in  the  description  thus  a  loop  is  required. 

—  Set  iterator  to  first  line  of  description. 

Environment .Types . Text.Buffer. Package . Init ialize.lt erator 

(The.Iterator ,  The. Act.Record. Descript ion) ; 

—  Engage  loop  to  get  each  line  of  the  description  and 

—  make  it  a  fact.  This  loop  is  0(x)  time  where  x  is  the 

—  number  of  lines  in  the  description. 

while  not  Environment.Types .Text .Buff er.Package . Is.Done 
(The.Iterator)  loop 

—  Retrieve  a  single  line  of  text.  0(1)  time. 
A.Description.Line:=  Environment.Types .Text.Buff er.Package. 
Value.Of .Item(The.Iterator) ; 

—  Create  a  fact  representing  a  single  line  of  the  description. 
A.Fact:=  Bleink.Fact; 

A.Fact(1..8)  :=  "act-desc*' ; 

A.Fact(9)  :=  *  *; 

A.FactdO. . 34)  :=  The. Act.Record. Name; 

A.Fact(35)  :=  »  *; 

A.Fact(36, .95) :=  A.Description.Line ; 

—  Store  this  fact  in  the  fact  buffer.  0(1)  time. 
Environment.Types .Fact.Buff er.Package. Add.It em 
(A. Fact,  Fact.Manager ,  Fact. Pointer ) ; 

—  Advance  pointer  by  one  to  next  line. 

Environment .Types. Text. Buff er.Package. Get. Next (The.Iterator) ; 
end  loop; 
end  if; 


—  If  the  activity  child  list  is  null  then  only  a  single  fact  is 

—  created  regardless  of  the  flag  setting. 

if  Environment.Types .Data. Buff er.Package. Is. Empty 
(The. Act. Record. Children)  then 

—  Create  a  null  fact. 

A.Fact:=  Blank. Fact; 
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A^Fact(l.  .13)  :=  "act-has-child'*; 

A^Fact(14)  :=  »  »; 

A_Fact(16.  .39)  :=  The.Act^ecord.Name ; 

A_Fact(40)  ;=  »  »; 

A_Fact(41.  .44):=  •'null”; 

—  Store  this  fact  in  the  fact  buffer.  0(1)  time. 

Environment ^Types .Fact^Buffer^Package.Add^Item 
(A_Fact,  Fact.Meoiager,  Fact^Pointer) ; 

—  At  this  point,  regardless  of  the  flag  setting,  all  the  children 

—  are  put  into  the  fact  buffer.  Thus,  the  same  facts  go  to 

—  either  the  .esm  file  or  the  expert  system, 
else 

—  Set  iterator  to  first  child  in  list. 

Environment .Types .Data_Buffer_Package . Initialize.Iterator 
(Child.Iterator,  The. Act.Record. Children) ; 

—  Engage  loop  to  get  each  child  and 

—  make  it  a  fact.  This  loop  is  0(z)  time  where  z  is  the 

—  number  of  children. 

while  not  Environment  .Types .  Data.Buf  f  er.Package .  Is.Done 
(Child.Iterator)  loop 

—  Retrieve  a  single  line  of  text.  0(1)  time. 

A.Child: =  Env ironment. Types .Data.Buf f er.Package. 

Value.Of .Item(Child.Iterator) ; 

—  Create  a  fact  representing  a  single  line  of  the  descrption. 
A.Fact:=  Blank.Fact; 

A.Factd.  .13)  :=  “act-has-child'*; 

A.Fact(14)  :=  * 

A.Fact(16. .39)  :=  The.Act. Record. Name; 

A.Fact(40)  :=  *  d 
A.Fact(41. .65):=  A.Child; 

—  Store  this  fact  in  the  fact  buffer.  0(1)  time. 

Environment .Types .Fact .Buff er.Package . Add.Item 
(A.Fact,  Fact.Manager ,  Fact.Pointer) ; 

—  Advance  pointer  by  one  to  next  line. 

Environment .Types .Data.Buf f er.Package. Get.Next (Child.Iterator) ; 
end  loop; 
end  if; 

—  Advance  pointer  to  next  activity  in  manager. 

—  Activity.Manager. Advance.lt erator.To.Next.Activity; 

—  Should  This  be  at  the  end  of  Retrieve  Activity*^? 

*:^^t*****^  Added  new  facts  from  Activity  Reference  Type  12/08/90 
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—  Author:  Min-fuh  Shyong  *♦♦♦♦♦ 

~  Create  Activity  reference  type  facts  ♦iit*j*ciit**j|t******>it% 


A^Fact  :=  Blank^Fact; 

A_Fact(l.  .12)  :=  ’’act-ref-type** ; 

A.Fact(13)  :=  ^  »; 

A_Fact(14, .38)  :=  The. Act^Record. Name; 

A_Fact(39)  :=  '  »; 

if  The.Act .Record. Ref erence.Type  /=  Environment .Types. Null.Reference.Type  then 
A.Fact(40. .64)  :=  The. Act .Record. Ref erence.Type; 


else 

A.Fact(40. .43)  :=  "null"; 
end  if; 


Environment .Types . Fact.Buf f er.Package . Add.Itera 
(A.Fact,  Fact .Manager ,  Fact.Pointer) ; 

—  (act- ref-type  Name  Ref erence.Type)  or 

—  (act-ref -type  Name  null) 

—  Create  one  or  more  activity  reference  facts  - 

—  if  the  activity  reference  is  null  then  only  a  single  fact  is  created 

—  regardless  of  the  flag  setting 


if  Environment .Types .Text.Buf f er.package . Is.Empty 
(The.Act.Record, Reference)  then 
—  true  it  is  empty 


A.Fact 

A.Factd.  .7) 
A.Fact(8) 
A.Fact(9. .33) 
A.Fact(34) 
A.Fact (35. .38) 


Blank.Fact ; 

"act-ref"; 

>  ) . 

The.Act.Record . Name ; 

}  ) . 
f 


"null"; 


(act-ref  Name  null) 


Environment .Types . Fact.Buf fer. Package . Add.Item 
(A.Fact,  Fact.Manager ,  Fact.Pointer); 

elsif  Type.Facts.Flag  =  false  then 

A.Fact  :=  Blank.Fact; 

A.Factd.. 7)  :=  "act-ref"; 

A.Fact (8) 

A.Fact(9. .33)  :=  The. Act. Record. Name; 
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A^Fact(34) 

A^Fact (35 . . 42)  : =  "not-null" ; 

—  (act-rel  Name  not-null) 

Environment.Types .Fact^Bulfer^Package . Add.Itein 
(A^Fact,  Fact^Manager ,  Fact^Pointer) ; 

else 

—  Hag  is  true  the  file  to  ,esm  file,  may  be  multiple  line  of 
—  reference  so  need  a  loop  to  get  it 

Environment ^Types .Text_Buffer.Package . Initial ize^Iterator 
(Ref erence^Iterator,  The.Act.Record, Reference) ; 

—  Engage  a  loop  to  get  each  line  of  the  reference  and  make  it  a  fact 

while  not  Environment _Types.Text„Buffer_Package.Is_Done 
(Ref erence^Iterator)  loop 

A.Reference^Line  := 

Environment .Types . Text.Buf f er.Package . 
Value.Of.Item(Reference.Iterator) ; 


A.Fact  :=  Blank.Fact; 

A.Fact(1..7)  :=  “act-ref’*; 

A.Fact(8)  :=  *  *; 

A.Fact(9. .33)  :=  The.Act.Record.Name; 

A.Fact(34)  :=  *  *; 

A.Fact(36 . .94)  :=  A.Ref erence.Line; 

Environment. Types . Fact. Buffer .Package . Add.Item 
(A.Fact,  Fact. Manager ,  Fact.Pointer) ; 

Environment .Types .Text. Buff er.Package. Get.Next (Ref erence. Iterator) ; 

end  loop; 

end  if;  —  (act-ref  Name  Ref erence-Linel) 

—  (act-ref  Name  Ref erence-Line2) 

—  Create  Activity  Version  facts 

A.Fact  :=  Blank.Fact; 

A.Factd. .  11)  :=  “act-version”; 

A.Fact (12)  :=  *  *; 

A.Fact (13. .37)  :=  The.Act. Record. Name; 

A.Fact (38)  :=  *  *; 

if  The. Act. Record. Version  /=  Activity. Class . Null.Activity.Version.number  then 
A.Fact (39. .48)  :=  The. Act.Record . Version; 
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else 


A«Fact(39..42)  :=  "null'*; 
end  il; 

Environment ^Types . Fact^Buf i er^Package . Add^It em 
(A.Fact,  Fact^Manager,  Fact^Pointer) ; 

—  (act-version  Name  Activity-Version)  or 

—  (act-version  Name  null) 

—  ](e4c4t  Create  one  or  more  activity  Version-Changes  lacts - 

—  il  the  activity  version  changes  is  null  then  only  a  single 

—  fact  is  created  regaordless  ol  the  flag  setting 

if  Environment _Types .Text^Buf f er^package . Is^Empty 
(The^Act ^Record . Vers ion^Changes )  then 
—  true  it  is  empty 

A.Fact 

A^Factd.  .11) 

A_Fact(l2) 

A_Fact(13. .37) 

A^Fact (38) 

A^Fact(39. .42) 

Environment ^Types . Fact^Buf f er_Package . Add^Item 
(A_Fact,  Fact_Manager,  Fact^Pointer) ; 


Blank^Fact ; 

=  "act-ver-chg" ; 

—  >  > . 

—  » 

=  The_Act_Record.Naaiie; 

}  > « 
t 

"null"; 


elsif  Type^Facts^Flag  =  false  then 

A_Fact  :=  Blank^Fact; 

A_Fact(l . . 11)  :=  "act-ver-chg"; 
A„Fact(12)  :=  *  »; 

A^Fact ( 13 . . 37)  : =  The_Act_Record . Name ; 
A^Fact(38)  :=  »  *; 

A_Fact(39. .46)  :=  "not-null"; 

Environment^Types . Fact^Buf fer.Package . Add.Item 
(A^Fact,  Fact^Manager ,  Fact^Pointer) ; 


else  —  version  not  empty  show  the  version  changes  to  .esm  — 

Environment slypes . Text.Buf f er_Package . Initial ize_Iterator 
(Version_Iterator ,  The_Act_Record. Version^Changes) ; 

—  Engage  a  loop  to  get  each  version  of  changes  and  make  it  a  fact 

while  not  Environment„Types .Text_Buf f er^Package. Is_Done 
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(Version_Iterator)  loop 


Version_Line  := 

Eiivironment_Type3 . Text.Bulf er_Package . Value.Of _Item(Version_Iterator) ; 


A.Fact  :=  Blank^Fact; 

A^Factd.  ,11)  :=  "act-ver-chg**; 

A«Fact(l2) 

A_Fact(l3 . .37)  :=  The^Act^Record.Name; 

A_Fact(38)  :=  »  »; 

A_Fact(39. .98)  :=  Version.Line ; 

--  (act-ver-chg  Name  null) 

—  (act-ver-chg  Name  Version-changes) 

Environment _Types . Fact^Bulf er.Package » Add^Item 
(A.Fact,  Fact^Manager,  Fact.Pointer) ; 

Enviroiunent.Types.Text^Buffer^Package.Get^Next(Version.Iterator); 

end  loop; 
end  il; 


—  ♦♦♦♦Create  Activity  Date  Fact  - - 

A_Fact:=  Blank^Fact; 

A^Fact(1..8)  :=  **act-date"; 

A^Fact(9)  :=  >  »; 

A_Fact(10 . . 34)  :=  The_Act_Record.Kame; 

A_Fact(35)  :=  * 

if  The.Act ^Record. Date  /=  Environment.Types.Null.Date  then 
A.Fact(36. .43)  :=  The_Act_Record,Date; 

else 


A^Fact(36, .39)  :=  "null"; 
end  if; 


Store  this  date  fact  in  the  fact  buffer.  0(1)  time. 
Environment ^Types . Fact.Buf f  er^Package . Add^It em 
(A_Fact,  Fact^McJiager ,  Fact^Pointer) ; 

—  (act-date  Name  mm/dd/yy) 

—  (act-date  Naane  null) 

♦♦♦♦Create  Activity  Author  Fact^+^+ - 

A^Fact:=  Blank^Fact; 

A^Fact (1 . . 10)  :=  "act-author"; 
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A^Factdl)  ; 

A^Fact ( 12 . . 36 )  : =  The^Act.Record . Name ; 

A^Fact(37)  :=  »  »; 

—  This  if  then  construct  determines  what  goes  into  the  last  field. 

—  If  the  activity  author  is  not  null  then  create  a  fact  with  the 

—  activity  author  in  it.  Flag  setting  doesn't  matter  here. 

if  The^Act ^Record . Author  /=  Environment.Types .Null. Author .Name  then 

—  All  statements  modeled  as  0(1)  time. 

A.Fact(38. .62)  :=  The. Act .Record. Author; 

else 

—  The  activity  author  is  null,  so  create  a  null  fact  for 

—  either  the  .esm  file  or  the  expert  system.  Again,  the  flag 

—  setting  does  not  matter.  All  0(1)  time. 

A.Fact(38..41)  :=  "null“; 

end  if; 

—  Store  this  fact  in  the  fact  buffer.  0(1)  time. 

Enviroiunent .Types . Fact.Buf f er.Package . Add. It era 

(A.Fact,  Fact .Manager ,  Fact.Pointer) ; 

—  Advance  pointer  to  next  activity  in  manager. 

Act iv it y. Manager . Advance.Iterator.To.Next .Activity ; 


end  loop; 

—  Outer  loop  for  Retrieve.Activity.Facts; 
end  Retrieve.Activity.Facts; 


—  DATE:  2/19/91 
~  VERSION:  1.0 

— •  NAME:  ***PR0CEDURE  RESTORE  ACTIVITY  FACTS*** 

—  MODULE  NUMBER:  TBD 

—  DESCRIPTION:  This  procedure  accepts  a  buffer  of  activity  facts  and  — 

—  restores  that  information  into  the  activity  manager.  Of  special 

—  note  is  that  the  procedure  assumes  the  facts  are  in  the  same  order  — 

—  in  which  they  were  stored. 

—  ALGORITHM:  A  single  while  loop  controls  the  execution  with  an 

—  embedded  call  to  an  0(i)  procedure. 

—  PASSED  VARIABLES:  The.Fact.Buff er  (contains  the  facts) 

—  RETURNS:  None 

—  GLOBAL  VARIABLES  USED:  None 

—  GLOBAL  VARIABLES  CHANGED:  None 
FILES  READ:  None 

—  FILES  WRITTEN:  None 

—  HARDWARE  INPUT:  None 
~  HARDWARE  OUTPUT:  None 
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—  MODULES  CALLED:  None 

— •  CALLING  MODULES:  Essential^IO.Restore^Project 

—  ORDER-OF:  order  oi  is  0(a  ♦  max  (x,  z  ♦  (a  *  z)))  where  a  is  the 

—  number  of  activities,  x  is  the  number  oi  lines  in  a  description 

—  and  z  is  the  number  oi  children  that  an  activity  has.  Note  that 

—  this  order  oi  may  change  when  more  oi  the  activity  manager  facts 

—  are  restored. 

—  Note  that  all  string  slice  operations  are  modeled  as  0(1)  time. 

—  AUTHOR(S):  Terry  Kitchen  and  Min-fuh  Shyong 

—  HISTORY:  None  (Initial  Implementation) 


procedure  Restore.Activity.Facts 
(The.Fact.Bufler  :  in 

Environment.Types . Fact^Buf f er^Package . Mamager^Type )  is 

—  Local  Declarations  — • 

Fact^Pointer :  Environment^Types .Fact_Buffer_Package. Iterator „Type; 

A^Fact :  Environment .Types . Fact.String.Type ; 

First. Char:  natural :=  0; 

Char.Position:  natural :=  0; 

Temp.Pos:  natural :=  0; 

More.Descriptions.Flag:  boolean; 

—  Activity  Related  Declarations  — 

Activity.Record :  Activity .Class . Act ivity.Record.Type ; 

Activity.Pointer:  Activity.Manager, Activity.Pointer.Type; 
Null.Activity.Record:  Act ivity.Class . Act ivity.Record.Type ; 

The.Iterator :  Environment .Types . Text.Buf f er.Package . It erator.Type ; 

A.Descr ipt ion.Line :  Environment .Types . DD .Text .Type ; 

A.Child :  Environment.Types . DD.Field.Type ; 

A.Ref erence.Line  :  Environment.Types .DD .Text .Type; 

Version.Line  :  Environment.Types . DD .Text .Type ; 

Found.Flag:  boolean :=  False; 

Result.Flag:  boolean; 

—  Exception  — 

—  This  exception  is  declared  here  because  the  Essential  10  package  does 

—  not  check  to  see  the  facts  are  in  any  specific  order. 

Invalid.Fact.Sequence.For.Activity :  exception ; 
Activity.Hierarchy.Error.During.Restore:  exception; 


begin 

—  Check  for  empty  buffer  of  facts.  If  empty,  do  nothing, 
if  Environment .Types. Fact. Buff er.Package .Is_Empty(The.Fact. Buffer)  then 
return; 


end  if; 


—  Initialize  iterator  to  first  fact. 

Environroent_Types . Fact^Buf f er^Package . Initial ize.Iterator 
(Fact^Po inter,  The^Fact.Buf f er) ; 

—  Engage  loop  to  extract  the  activity  facts  from  a  buffer 

—  one  at  a  time.  This  loop  will  execute  a  times  —  once  for 

—  each  activity.  Note  that  there  are  many  facts  associated  with 

—  a  single  activity.  This  loop  runs  a  times.  The  loop  has  one 

—  inner  loop  of  order  x  and  one  procedure  call  of  (a  *  z).  Thus, 

—  order  of  is  0(a  *  max  (x,  z*(  a  ♦  z)  )  ) 


While  not  Environment _Types.Fact_Buffer_Package.Is_Done(Fact_Rointer)  loop 

—  Get  a  record. 

A^Fact : =  Environment „Types . Fact.Buf f er^Package . Value^Of _Item 
(Fact^Pointer) ; 

—  Since  we  put  the  information  in  the  string,  we  know  the 

—  exact  columns  where  information  should  be. 

—  All  string  assignments  are  modeled  as  0(1); 

—  Insure  the  fields  are  all  blanks. 

Activity_Record:=  Null^Activity.Record; 

—  The  first  fact  should  be  the  name, 
if  A_Fact(1..8)  /=  "act-name”  then 

Text.IO .Put_Line(A_Fact) ; 

Text_IO.Put_Line("I  am  Exp:  act -name  "); 

raise  Invalid_Fact_Sequence_For_Act ivity ; 
end  if; 

—  The  activity  name  must  be  in  columns  10  through  34. 

Activity.Record . Name : =  A_Fact ( 10 . . 34) ; 

—  Check  to  see  if  activity  already  exists.  0(a)  call. 

Activity^Manager . Activity^Exists (Activity^Record . Name , 

Activity^Pointer,  Found^Flag) ; 
if  Found^Flag  =  False  then 

—  Do  0(a  *  z)  procedure  call  to  create  an  activity. 
Activity^Manager.Create.Activity 

( Activity_Record . Name ,  Activity^Pointer ) ; 
end  if; 

—  Advance  pointer  to  next  fact  in  manager.  0(1). 

Environment _Types.Fact_Buffer_Package. Get _NextfFact_Pointer) ; 

—  Get  a  fact.  0(1)  time. 

A^Fact : =  Environment^Types . Fact^Buf f  er.Package . Value_0f _It em 
(Fact.Pointer) ; 
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—  This  fact  should  be  the  activity  number, 
if  A_Fact(1..8)  /=  "act-numb**  then 

Text_IO.Puc_Line(A_Fact) ; 

Text^IO.Put.LineC'I  am  Exp:  act-numb  **); 
raise  Invalid_Fact_Sequence_For_Activity ; 
end  if; 

—  Columns  10  through  34  must  be  the  same  activity  name, 
if  A_Fact(10, .34)  /=  Act ivity^Record. Name  then 

Text_IO,Put_Line(A^Fact) ; 

Text _I0. Put _Line(**I  am  Exp:  act-numb. Name  **); 
raise  Inval id^Fact _Sequence_For „ Act iv ity ; 
end  if; 

—  Columns  36  through  66  hold  the  activity  number  if  it  is 

—  not  null. 

if  A_Fact(36.  .39)  =  "null**  then 

—  Do  nothing,  there  was  no  activity  number, 
null; 

else 

—  Get  the  number. 

Activity .Record . Number : =  A.Fact (36 . . 65) ; 

—  Do  0(1)  procedure  call  to  update  the  activity  in  the  activity 

—  manager. 

Activity.Manager . Set.Activity.Number 

(Activity.Pointer,  Act ivity.Record. Number) ; 
end  if; 

—  Advance  pointer  to  next  fact  in  manager. 

Environment  .Types  .Fact  .Buff  er.Package.Get.Next(Fact.Pointer) ; 

—  If  the  fact  buffer  is  empty  at  this  point  there  is  cm  error 

—  in  the  format. 

if  Environment .Types. Fact.Buffer .Package. Is.Done(Fact_Pointer)  then 
Text_IO.Put.Line(A.Fact) ; 

Text.IO.Put.Line(*'I  am  Exp:  act-name  Is.Done  "); 
raise  Invalid.Fact.Sequence.For.Activity ; 
end  if; 

—  Get  a  fact. 

A.Fact :=  Environment .Types .Fact .Buff er.Package.Value.Of. Item 
(Fact.Pointer) ; 

—  The  series  of  fact(s)  should  be  the  activity  description. 

—  There  is  at  least  one  act-desc  fact  and  possible  more, 
if  A_Fact(1..8)  /=  "act-desc"  then 

Text.IO.Put.Line(A.Fact) ; 

Text_IO.Put.Line("I  am  Exp:  act-desc  "); 
raise  Invalid.Fact.Sequence.For.Activity ; 
end  if; 

—  Columns  10  through  34  must  be  the  same  activity  name. 
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if  A^FactdO.  .34)  /=  Activity  .Record.  Name  then 
Text. 10 .Put .Line (A.Fact) ; 

Text.IO.Put.Line('*I  am  Exp:  act-desc.Name  '*); 
raise  Invalid.Fact.Sequence.For.Act ivity ; 
end  if; 

—  If  the  description  is  null  then  we  are  done  with  this  attribute. 

—  Need  only  to  advance  the  pointer  by  one  for  the  outer  loop, 
if  A. Fact (36.  .39)  =  "null*'  then 

—  There  is  no  description  for  the  activity,  so  just  advance 

—  the  fact  pointer. 

—  Advance  pointer  to  next  fact  in  manager.,  0(1)  time. 

Environment .Types . Fact.Buf f er.Package . Get.Next (Fact.Pointer) ; 

else 

—  There  must  be  one  or  more  lines  in  the  description. 

—  This  loop  will  run  x  times  where  x  is  the  number  of  lines  in  the 

—  description., 

while  A_Fact(1..8)  =  "act-desc**  loop 

—  I  realize  this  check  is  repetitive  on  the  first  iteration. 

—  Columns  10  through  34  must  be  the  same  activity  name. 

—  0(1)  time  complexity. 

if  A.Fact(10. .34)  /=  Act ivity.Record. Name  then 
Text. 10 . Put .Line ( A.Fact ) ; 

Text. 10.  Put  .Line  ("I  am  Exp:  act-desc.Name  else  *'); 
raise  Invalid.Fact.Sequence.For.Activity ; 
end  if; 

—  Pull  the  description  from  the  fact. 

A.Description.Line: =  A.Fact (36. .95); 

—  Add  the  description  to  the  description  part  of  the 

—  activity  record.  0(1)  time. 

En V ir onment .Type  s . Text .Buf f  er.Package . Add.I t  em 

(A.Description.Line, Act ivity.Record. Description, The.Iterator) ; 

—  Advance  pointer  to  next  fact  in  manager. 

Environment .Types . Fact.Buf f er.Package . Get.Nt.xt (Fact.Pointer) ; 

—  If  it  is  not  empty  get  the  next  fact.  0(1)  time, 
if  not  Environment.Types.Fact.Buff er.Package. I s.Done 
(Fact.Pointer)  then 

A.Fact : =  Environment .Types . Fact.Buf f er.Package . Value.Of .Item 
(Fact.Pointer) ; 

else 

”  If  this  is  the  last  fact  of  the  last  activity  exit  the 
—  loop, 
exit; 
end  if; 
end  loop: 
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—  There  were  one  or  more  lines  in  the  description  so  now  must 

—  place  them  with  the  activity  in  the  activity  manager.  0(1). 

Act  ivity_Manager.Set_Activity  ..Description 

(Activity..Pointer,  Activity^Record. Description) ; 

end  if; 

—  If  the  fact  buffer  is  empty  at  this  point  there  is  an  error 

—  in  the  format,  0(1)  time.  I  know  this  because  Retrieve„Activity_ 

—  Facts  will  at  least  put  a  null  entry  for  no  children. 


if  Environment..Types .Fact_Buff er.Package. Is_Done(Fact,Pointer)  then 
Text  ..10 .  Put  ..Line  ( A_Fact ) ; 

Text_IO.Put_Line("I  am  Exception:  act-has-child  Is.Done  ”); 
raise  Invalid_Fact_Sequence_For .Activity ; 
end  if; 


—  Get  a  fact. 

A.Fact : =  Environment .Types . Fact.Buf f  er.Package . Value.0f.lt em 
(Fact .Pointer) ; 

—  The  series  of  fact(s)  should  be  the  activity  description. 

—  There  is  at  least  one  act-desc  fact  and  possible  more, 
if  A.Fact(l . . 13)  /=  "act-has-child”  then 

Text.IO . Put.Line("I  am  Exp: act-has-child  "); 
raise  Invalid.Fact.Sequence.For.Activity; 
end  if; 

—  Columns  15  through  39  must  be  the  scone  activity  name, 
if  A_Fact(15. .39)  /=  Activity.Record.Name  then 

Text.IO. Put_Line("I  am  Exp:  act-has-child. Name  "); 
raise  Invalid.Fact.Sequence.For.Activity; 
end  if; 

—  If  the  child  list  is  null  then  we  are  done  with  this  attribute. 

—  Need  only  to  advance  the  pointer  by  one  for  the  outer  loop. 

if  A.Fact(41. .44)  =  "null"  then 

—  There  is  no  child  list  for  the  activity,  so  just  advance 
—  the  fact  pointer. 

—  Advance  pointer  to  next  fact  in  manager.  0(1)  time. 
Environment.Types . Fact.Buffer. Package .Get. Next (Fact. Pointer) ; 
else 

—  There  must  be  one  or  more  children. 

—  This  loop  will  run  z  times  where  z  is  the  number  of  children, 
while  A.Fact(l . . 13)  =  "act-has-child"  loop 

—  I  realize  this  check  is  repetitive  on  the  first  iteration. 
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—  Columns  15  through  39  must  be  the  same  activity  name. 

—  0(1)  time  complexity. 

il  A_Fact(15. .39)  /=  Activity.Record.Name  then 
Text_IO.Put_Line('*I  am  Exp:  act-has-child  whild  "); 
raise  Invalid_Fact_Sequence_For_Act ivity ; 
end  if; 

—  Pull  a  child  from  the  fact. 

A_Child:=  A_Fact(41 . .65) ; 

—  In  order  to  add  a  child  to  a  parent,  the  Activity  Manager 

—  requires  that  the  child  already  exist  as  an  activity. 

—  Thus,  must  create  the  activity  first  if  needed. 

—  Check  to  see  if  activity  already  exists.  0(a)  call. 

Act ivity^Manager . Act ivity_Exist s ( A.Child , 

Activity.Pointer ,  Found_Flag); 
if  Found_Flag  -  False  then 

—  Do  0(a  *  z)  procedure  call  to  create  an  activity. 
Activity^Kanager . Create.Activity 
(A_Child,  Activity^Pointer) ; 
end  if; 

—  Do  another  0(a  *  z)  procedure  call  to  add  this  activity 

—  to  the  parent's  child  list. 

Act  ivity_Manager.Add_Activity_Child  (Act  ivity.Record.  Name, 
A_Child,  Result_Flag) ; 

—  Check  results . 

if  Result^Flag  =  False  then 

Text„IO.Put„Line(,'‘I  am  Exp;  act-has-child  flag  "); 

raise  Activity_Hierarchy_Error„During_Restore ; 
end  if; 

—  Must  now  call  Activity  Exists  again  in  order  to  reset  the 

—  pointer  for  any  future  operations.  0(a)  time. 
Activity^Manager . Activity_Exists( Activity^Record . Name , 

Activity_Pointer ,  Found^Flag) ; 

—  Advance  pointer  to  next  fact  in  manager. 

Environment_Types .Fact_Buff er.Package. Get_Next(Fact_Pointer) ; 

—  If  it  is  not  empty  get  the  next  fact.  0(1)  time, 
if  not  Environment _Types.Fact_Buffer_Package. Is.Done 

(Fact_Pointer)  then 

A^Fact ; =  Environment .Types .Fact_Buffer.Package.Value_Of_item 
(Fact.Pointer) ; 

else 

—  If  this  is  the  last  fact  of  the  last  activity  exit  the 

—  loop, 
exit; 

end  if ; 
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end  loop; 
end  if; 


if  Environme)it_Types .Fact .Buffer ^Package . Is.done (Fact. Pointer)  then 
Text_IO.Put.Line(A.Fact) ; 

Text.IO.Put.LineC'I  am  Exp:  act-ref-type  -  Is.done  "); 
raise  Invalid.Fact.Sequence.For.Activity; 
end  if; 


— '  Advance  pointer  to  next  fact  in  manager.  0(1). 

—  Environment .Types .Fact.Buffer.Package.Get_Next(Fact.Pointer) ; 

—  this  will  cause  the  fact  get  next  act-ref  fact  ealier  than 

—  expected! I  I 

—  Get  a  fact.  0(1)  time. 

A.Fact : =  Environment .Types . Fact.Buf f er.Package . Value.Of .Item 
(Fact. Pointer) ; 


if  A.Fact(l .  .  12)  /=  "act-ref-type*'  then 
Text.IO. Put _Line( A.Fact) ; 

Text.IO.Put_Line("I  am  Exp: act-ref -type  "); 
raise  Invalid.Fact.Sequence.For.Activity ; 
end  if ; 


—  Columns  14  through  38  must  be  the  same  activity  name, 
if  A.Fact (14. . 38)  /=  Act ivity.Record. Name  then 

Text.IO.Put.Line("I  am  Exp:  act-ref -type. neone  "); 
raise  Invalid.Fact.Sequence.For.Activity ; 
end  if; 

—  Columns  40  through  64  hold  the  activity  Reference  Type  if  it  is 
—  not  null. 


if  A.Fact (40. .43)  =  "null"  then 

—  Do  nothing,  there  was  no  activity  Reference  Type. 

null; 

else 


—  Get  the  Reference  type 


Activity.Record.Ref erence.Type:=  A.Fact (40. .64); 

—  Do  0(1)  procedure  call  to  update  the  activity  in  the  activity 
—  mainager. 

Activity.Mcinager . Set.Activity.Ref erence.Type 

(Activity. Pointer ,  Act ivity.Record. Ref erence.Type) ; 
end  if; 
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—  Advance  pointer  to  next  fact  in  manager. 

Environment^Types .Fact^Buff er^Package .Get„Next(Fact_Pointer) ; 

—  If  the  fact  buffer  is  empty  at  this  point  there  is  an  error 
—  in  the  format. 

if  Environment_Types.Fact_Buff er^Package. Is_Done(Fact_Pointer)  then 
Text_IO.Put_Line(A.Fact) ; 

Text_IO.Put_Line(‘*I  am  Exp:  act-ref  Is^Done  ”); 
raise  Invalid_Fact_Sequence_For_Activity; 
end  if; 

—  Get  a  fact. 

A^Fact : =  Environment _Types .Fact _Buffer„Package .Value_Of_Item 
(Fact.Pointer) ; 


—  The  series  of  fact(s)  should  be  the  activity  Reference. 

—  There  is  at  least  one  act-ref  fact  and  possible  more, 
if  A_Fact(1..7)  /=  “act -ref"  then 
Text_IO.Put_Line(A_Fact) ; 

Text_IO.Put.Line("I  am  Exp:  act-ref  "); 
raise  Invalid_Fact„Sequence_For_Activity ; 
end  if; 

—  Columns  9  through  33  must  be  the  same  activity  name, 
if  A^Fact(9. .33)  /=  Act ivity_Record. Name  then 

Textile. Put .LineC'I  am  Exp:  act-ref. Name  1  "); 

raise  Invalid_Fact_Sequence_For_Activity; 
end  if; 

—  If  the  Reference  is  null  then  we  are  done  with  this  attribute. 
—  Need  only  to  advance  the  pointer  by  one  for  the  outer  loop. 

if  A.Fact(35..38)  =  "null"  then 

—  There  is  no  reference  for  the  activity,  so  just  advance 

—  the  fact  pointer. 

—  Advance  pointer  to  next  fact  in  manager.  0(1)  time. 

Environment _Types .Fact_Buffer_Package.Get_Next(Fact_Po inter) ; 

else 

—  There  must  be  one  or  more  lines  in  the  reference. 

—  This  loop  will  run  x  times  where  x  is  the  number  of  lines  in  the 
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—  reference. 

while  A_Fact(1..7)  =  "act-ref"  loop 

—  I  realize  this  check  is  repetitive  on  the  first  iteration. 

—  Columns  9  through  33  roust  be  the  saroe  activity  name. 

—  0(1)  time  complexity, 

if  A„Fact(9, . 33)  /=  Activity^Record.Name  then 

Text_IO.Put_Line("I  am  Exp:  act-ref .Ncune  2  "); 

raise  Invalid_Fact_Sequence_For_Activity ; 
end  if; 

—  Pull  the  reference  from  the  fact. 

A^Ref erence_Line:=  A^Fact(35. .94); 

—  Add  the  reference  to  the  reference  part  of  the 

—  activity  record.  0(1)  time. 

Environment „Types .Text^Buf f er.Package . Add.Item 

(A_Reference^Line,Activity_Record.Ref erence,The_Iterator) ; 

—  Advance  pointer  to  next  fact  in  manager. 

Environment „Types . Fact 3uffer_Pdckage. Get _Next(Fact^Pointer) ; 

—  If  it  is  not  empty  get  the  next  fact.  0(1)  time, 
if  not  Environment.Types .Fact^uff er^Package. Is^Done 
(Fact_Pointer)  then 

A^Fact : =  Environment_Types . Fact_Buf f er_Package . Value^Of .Item 
(Fact.Pointer) ; 

else 

—  If  this  is  the  last  fact  of  the  last  activity  exit  the 
—  loop. 

Text.IO.Put.Line("I  am  Exp:  act-ref  else  "); 

—  raise  Invalid.Fact.Sequence.For.Activity ; 

exit ; 

end  if; 
end  loop; 

—  There  were  one  or  more  lines  in  the  description  so  now  must 

—  place  them  with  the  activity  in  the  activity  manager.  0(1). 

Activity.Manager.Set.Activity.Ref erence 

(Activity.Pointer,  Activity.Record. Ref erence) ; 

end  if; 


if  Environment.Types .Fact. Buff er.Package . Is.done (Fact.Pointer)  then 
Text.IO.Put_Line("I  am  Exp:  act-version  Is.done  "); 
raise  Invalid.Fact.Sequence.For.Activity ; 
end  if ; 
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—  Advance  pointer  to  next  fact  in  manager.  0(1). 

— Environittent„T3rpes  .Fact3uffer^Package.Get.Next(Fact .Pointer) ; 

—  Get  a  fact,  0(1)  time. 

A.Fact : =  Enviroiment. Types . Fact.Buf f er_Package . Value.Of .Item 
(Fact. Pointer) ; 

—  This  fact  should  be  the  activity  Version. 

if  A.Factd.  .11)  /=  **act-version'*  then 

Text.IO.  Put  .Line  (**I  am  Exp:  act-version  "); 
raise  Invalid.Fact.Sequence.For. Activity; 
end  if; 


—  Columns  13  through  37  must  be  the  same  activity  naone. 
if  A.Fact(13. .37)  /=  Activity. Record. Name  then 

Text. 10.  Put. Line  (^*  I  cja  Exp:  act- vers  ion.  Name  "); 

raise  Invalid.Fact.Sequence.For. Activity; 
end  if; 


—  Columns  39  through  48  hold  the  activity  version  if  it  is 

—  not  null. 

if  A.Fact(39..42)  =  •'null**  then 

—  Do  nothing,  there  was  no  activity  version, 
null ; 

else 

—  Get  the  version. 

Act ivity.Record. Version :=  A.Fact(39. .48); 

—  Do  0(1)  procedure  call  to  update  the  activity  in  the  activity 

—  manager . 

Act ivity. Manager . Set .Act ivit y.Vers ion 

(Activity.Pointer,  Activity.Record. Version) ; 
end  if; 


—  get  Activity  Version  Changes  Facts  ♦♦♦  - 

—  Advaince  pointer  to  next  fact  in  raamager. 

Environment .Types .Fact.Buffer.Package.Get_Next(Fact.Po inter) ; 

—  If  the  fact  buffer  is  empty  at  this  point  there  is  an  error 

—  in  the  format. 


if  Environment .Types .Fact. Buff er .Package. Is.Done(Fact_Pointer)  then 
Text.IO. Put.LineC'I  am  Exp:  act-ver-chg  Is.Done  "); 
raise  Invalid.Fact.Sequence.For.Activity ; 
end  if ; 
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—  Get  a  fact. 

A^Fact :=  Environment ^Types .Fact.Buffer^Package.Value^Of .Item 
(Fact.Pointer) ; 


—  The  series  of  fact(s)  should  be  the  activity  Version  Cheinges. 

—  There  is  at  least  one  act-ver-chg  fact  and  possible  more, 
if  A.Fact(l . ,  11)  /=  *'act*“ver~chg"  then 

Text.IO.Put.LineC'I  am  Exp:  act-ver-chg  "); 
raise  Invalid.Fact.Sequence.For.Activity; 
end  if; 

—  Columns  13  through  37  must  be  the  same  activity  version  name, 
if  A_Fact(13. .37)  /=  Act ivity.Record. Name  then 

Text. 10. Put. Line ('* I  am  Exp:  act-ver-chg.Name  '*); 
raise  Invalid.Fact.Sequence.For.Activity ; 
end  if; 

—  If  the  version  change  is  null  then  we  are  done  with  this  attribute. 

—  Need  only  to  advance  the  pointer  by  one  for  the  outer  loop. 

if  A.Fact(39. .42)  =  "null"  then 

—  There  is  no  version  change  for  the  activity,  so  just  advance 

—  the  fact  pointer. 

—  Advance  pointer  to  next  fact  in  manager.  0(1)  time. 

Environment .Types . Fact .Buff  er.Package . Get.Next (Fact .Point er) ; 

else 

—  There  must  be  one  or  more  lines  in  the  version  changes. 

—  This  loop  will  run  x  times  where  x  is  the  number  of  times  in  the 

—  version  change. 


while  A.Factd . .  11)  =  "act-ver-chg"  loop 

—  I  realize  this  check  is  repetitive  on  the  first  iteration. 

—  Columns  13  through  37  must  be  the  same  activity  name. 

—  0(1)  time  complexity. 

if  A.Fact(13. .37)  /=  Act ivity.Record. Name  then 

Text.IO.Put_Line("I  am  Exp:  act-ver-chg.Name  in  loop  "); 
raise  Invalid.Fact. Sequence. For.Activity ; 
end  if; 

—  Pull  the  description  from  the  fact. 

Version.Line : =  A.Fact(39 . .98) ; 

—  Add  the  version  change  to  the  Version  Chainges  part  of  the 

—  activity  record.  0(1)  time. 


n-34 


Environment _Types .Text Juller^Package . Add^Item 

(Version.Line,  Activity^Record.Version^Changes,  The.Iterator) ; 

—  Advance  pointer  to  next  fact  in  manager. 

Environment ^Types . Fact.Buf ler^Package . Get^Next (Fact^Point er ) ; 

—  If  it  is  not  empty  get  the  next  fact.  0(1)  time, 
if  not  Environment _Types. Fact _Buf f er_Package. Is^one 

(Fact^Pointer)  then 

A^Fact : =  Environment .Types . Fact.Buff er.Package , Value.Of .Item 
(Fact.Pointer) ; 

else 

—  If  this  is  the  last  fact  of  the  last  activity  exit  the 
—  loop. 

— Text. 10. Put .Line ("I  am  Exp:  act-ver-chg  else  “); 

—  raise  Invalid.Fact.Sequence.For.Activity ; 
exit; 
end  if; 
end  loop; 


—  There  were  one  or  more  lines  in  the  version  changes  so  now  must 

—  place  them  with  the  activity  in  the  activity  manager.  0(1). 
Activity.Manager.Set.Activity.Version.Comments 

(Activity.Pointer,  Activity.Record. Version.Changes) ; 

end  if; 


— get  Activity  Date  Facts  *** 


if  Env ironment .Types .Fact .Buff er.Package.Is.done (Fact. Pointer)  then 
Text.IO.Put.Line('*I  am  Exp:  act-data  Is.done  '*); 

raise  Invalid.Fact.Sequence.For. Activity;  —  raised 
end  if; 


—  2/18/. 2340  Get.Next (Fact.Pointer) 

—  This  will  get  author  ealier 

—  Advance  pointer  to  next  fact  in  manager.  0(1). 

—  Environment.Types.Fact.Buffer.Package. Get.Next (Fact.Pointer) ; 
—  Get  a  fact.  0(1)  time. 

A.Fact : =  Environment .Types . Fact.Buf f er.Package . Value.Of .Item 
(Fact.Pointer) ; 

—  This  fact  should  be  the  activity  date, 
if  A_Fact(1..8)  /=  "act-date"  then 
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Text_IO.Put_Line(A_Fact) ; 

Text_IO.Put_Liiie('*I  am  Exp:  act-date  *'); 
raise  Invalid«Fact_Sequence_For_Activity ; 
end  ii; 

—  Columns  10  through  34  must  be  the  same  activity  name. 
if  A^FactdO.  .34)  /=  Act ivity^ecord. Name  then 

Text_IO.Put_Line(*'I  am  Exp:  act-data. Name  *'); 
raise  Invalid.Fact_Sequence_For_Activity; 
end  if] 

—  Columns  36  through  43  hold  the  activity  version  il  it  is 

—  not  null. 

if  A.Fact(36.  .39)  =  »*null"  then 

—  Do  nothing,  there  was  no  activity  version, 
null; 

else 

—  Get  the  date. 

Activity.Record.Date:=  A_Fact(36. .43); 

—  Do  0(1)  procedure  call  to  update  the  activity  in  the  activity 

—  manager. 

Activity^Manager . Set^Activity^Date 

(Activity^Pointer,  Activity^ecord.Date) ; 
end  ii; 

—  Get  Activity  Author  Facts  - 


if  Environment^Types .Fact_Buffer_Package . Is^done (Fact „Po inter)  then 
Text_IO.Put_Line(“I  am  Exp:  act-author  for  Is^done  '*); 
raise  Invalid_Fact_Sequence_For.Activity ; 
end  if; 


—  Advance  pointer  to  next  fact  in  manager.  0(1).. 
Environme’‘t_Types.Fact_Buffer_Package.Get_Next(Fact_Pointer) ; 
—  Get  a  fact.  0(1)  time. 

A_Fact : =  Environment^Types . Fact_Buf f er_Package . Value_0f _Itero 
(Fact^Pointer) ; 

—  This  fact  should  be  the  activity  author. 

if  A^Factd.  .10)  /=  *'act-author”  then 
Text_I0.Put_Line(A_Fact) ; 

Text_I0.Put_Line('*I  am  Exp:  act-author  ”); 
raise  Invalid_Fact_Sequence„For_Activity ; 
end  if; 
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—  Columns  12  through  36  roust  be  the  same  activity  name, 
if  A.Fact(12.  .36)  /=  Act ivity^Record. Name  then 

Text.IO.Put^LineC'I  am  Exp:  act-author  .Name  '*); 
raise  Invalid^Fact.Sequence^For^Activity; 
end  if; 

—  Columns  38  through  62  hold  the  activity  author  if  it  is 

—  not  null. 

if  A^Fact(38.  .41)  =  '•null'*  then 

—  Do  nothing,  there  was  no  activity  author, 
null; 

else 

—  Get  the  author. 

Act ivity_Record. Author :=  A„Fact(38. .62); 

—  Do  0(1)  procedure  call  to  update  the  activity  in  the  activity 

—  manager. 

Activity_Manager.Set_Activity_Author 

( Activity^Pointer ,  Activity_Record . Author) ; 
end  if; 

Environment ^Types .Fact ^Buffer.Package .Get^Next (Fact .Pointer) ; 


—  Note  that  the  last  if  then  construct  has  already  advanced  the  fact 

—  pointer  to  the  next  fact..  Thus,  there  is  no  need  to  advance  the 

—  pointer  here, 
end  loop; 

end  Restore_Activity„Facts; 


—  DATE:  2/19/91 

—  VERSION:  1.0 

—  NAME:  RETRIEVE  DATA  ELEMENT  FACTS 

—  MODULE  NUMBER:  TBD 

—  DESCRIPTION: 

When  the  flag  Type_Of_Facts_Flag  is  set  to  true, it  means  the  — 
client  procedure  wants  all  the  facts  that  are  necessary  for  — 
the  .esm  file.  If  the  flag  is  false,  then  the  facts  for 
the  expert  system  are  returned.  Facts  of  the  same  type  have  — 
the  same  format  no  matter  where  they  are  destined.  In  this  — 
case,  the  data  element  name  is  but  a  single  fact. 

—  data  element  facts:  (retrieved  when  creating  a  .esm  file  or 

when  performing  check  syntax) 

1)  a  predefined  attribute  name  (data-element-name) 

—  2)  the  data  element  name  (if  the  name  is  null,  the  word  ‘null'  is  — 

placed  in  the  field. 
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—  ALGORITHM:  All  simple  0(1)  statements  and  2  0(i;  procedure  calls,  — 

—  PASSED  VARIABLES:  Type.Facts.Flag,  Fact_Manager 

—  RETURNS:  Hone 

—  GLOBAL  VARIABLES  USED:  None 
““  GLOBAL  VARIABLES  CHANGED:  None 

—  FILES  READ:  None 

—  FILES  WRITTEN:  None 

—  HARDWARE  INPUT:  None 
“  HARDWARE  OUTPUT:  None 
--  MODULES  CALLED:  None 

—  CALLING  MODULES:  TBD 

—  ORDER-OF:  0(1) 

~  AUTHOR(S) :  Min-luh  Shyong 

—  HISTORY:  None  (Initial  Implementation) 


procedure  Retrieve_Data_Element .Facts 
(Type.Facts.Flag  :  in  boolean; 

Fact.Manager  :  in  out 

Environment .Types . Fact .Buff er.Package . Manager .Type)  is 


—  Local  Declarations  — 

Fact.Pointer •  Environment .Types .Fact.Buff er.Package . Iterator.Type; 

A.Fact :  Environment .Types . Fact.String.Type ; 

Blank.Fact:  Environment .Types . Fact.String.Type :=  (others  =>  *  O; 

—  Data  element  declarations  — 

Data.Element.Record  :  Data.Eleraent .Class . Data.Element.Record.Type ; 
Data.Element.Pointer  :  Data.Element .Manager . Dat a. Element. Point er.Type ; 

—  varribles  for  Values  (multi-field)  - 

Data.Ele.Values.Iteratoi : 

Environment .Types . Data.Buff er.Package . Iterator.Type ; 
Data.Ele.Values.Line :  Environment.Types . DD.Field.Type ; 

—  :(c4c3te4c  variables  for  description(multi-f ield)  - 

The. Iterator :  Environment.types .Text.Buff er.Package. Iterator.Type; 
A.Description.Line ;  Environment .Types . DD.Text.Type ; 

—  variables  for  Ref erence(multi-f ield)  - 

Reference. Iterator  : 

Environment.Types .Text.Buff er.Package . Iterator.Type; 
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A^Relerence^Line  :  Environment_Types.DD_Text_Type; 


—  variables  lor  changes (roultilield)  ♦♦♦  — 

Version^Iterator  :  Environment ^Types . Text^Buf 1 er^Package . Iterator.Type ; 

Version^Line  ;  Environment _Types.DD_Text_Type; 


begin 


begin 

—  Clear  the  passed  in  lact.manager,  0(1)  time. 
Environment  Jfypes,Fact3uller_Package  .Clear  (Fact^Manager) ; 

—  Set  pointer  to  beginning  ol  manager.  0(1)  time. 
Data_Element_Manager. Res et_Data_Element_ Iterator; 


—  Engage  loop  to  extract  the  facts  associated  with  am  data  element.  The 

—  facts  extracted  will  have  the  format  discussed  above.  If  there  are 

—  no  data  element,  this  loop  won't  execute  and  an  empty  buffer  is  the 

—  result. 

—  This  loop  runs  a  times  where  a  is  the  number  of  data  elements.  At  this 

—  time  there  is  only  one  iimer  loop  of  0(x)  time.  Thus,  the  time 

—  complexity  is  0(a  *  x) . 

while  not  Data^Element^Manager .Data_Element_Iterator„Done  loop 

—  outer  loop  — 

—  Get  a  record.'  0(1)  time. 

Data_Element_Record : =  Data_Element_Manager . 

Value^Of _Data_Element_At_Iterator ; 

—  Regardless  of  the  Type_Facts_Flag  setting,  the  data  element  name  is 

—  always  added  to  the  fact  buffer. 

—  Place  the  data  element  ncime  into  a  fact  string  at  specific  positions. 

—  Initialize  the  fact  string  to  all  blanks  first. 

—  All  string  assignments  are  modeled  as  0(1). 

—  ♦♦♦♦Create  Data  Element  Name  Fact^++^  - 

A_Fact:=  Blank.Fact; 

A_Fact(l .  .  17)  ;=  "data-element-naane" ; 

A^FactdS) 

if  Data_Eleroent_Record .Name  /=  Data.Element.Class .Null„Data„Element_Naine  then 
A_Fact (19.  .43)  :=  Data_Element_Record .Ncime ; 

else 

A_Fact(19. .22)  :=  “null"; 


end  if; 

—  Store  this  fact  in  the  fact  buffer.  0(1)  time. 

Environment.Types . Fact.Buf f er^Package . Add^Item 

(A^Fact,  Fact^Manager,  Fact.Pointer) ; 

— (data- element --name  Name) 
—  (data-element-name  null) 

—  ♦♦♦♦Create  Data  Element  Data^Type  Fact^^^^  - 

A_Fact:=  Blank^Fact; 

A^Factd. .  17)  :=  "data-element-type*'; 

A^FactdB) 

A_Fact(19. .43)  :=  Data_Element_Record.Name; 

A_Fact(44)  :=  »  d 


—  This  if  then  construct  determines  what  goes  into  the  last  field. 

—  If  the  data  element  data^type  is  not  null  then  create  a  fact  with  the 

—  data.type  in  it.  Flag  setting  doesn^t  matter  here, 
if  Data_Element_Record.Data_Type  /= 

Data_Element_Class .Null.Data_Element_Data_Type  then 

—  All  statements  modeled  as  0(1)  time. 

A_Fact(45. .69)  :=  Data_Element_Record.Data_Type; 

else 

—  The  activity  number  is  null,  so  create  a  null  fact  for 

—  either  the  .esm  file  or  the  expert  system.  Again,  the  flag 

—  setting  does  not  matter.  All  0(1)  time. 

A_Fact(45.  .48)  :=  ’'null”; 

end  if ; 

—  Store  this  cact  in  the  fact  buffer.  0(1)  time. 

Environmental ^  pes . Fact.Buf f  er^Package . Add_It era 

(A^Fact,  Fact^Manager,  Fact^Pointer) ; 

—  (data-element-type  Name  Data-Type) 

—  (data-element-type  Name  null) 

♦♦♦♦Create  Data  Element  minimum  Fact**^^  - 

A_Fact:=  Blank_Fact; 

A^Fact ( 1 . . 20 )  : =  "data-element -minimum” ; 

A^Fact(21)  :=  »  »; 

A..Fact(22. .46)  :=  Data„Element_Record.Name; 

A^Fac  [47) 

if  Data„Element_Record. Minimum  /= 

Data_Element_Class . Null_Data„Element_Value  then 
A_Fact(48. .62)  :=  Data_Element_Record. Minimum; 

else 

A.Fact(48. .51)  :=  "null”; 
end  if; 


—  store  this  fact  in  the  fact  buffer.  0(1)  time. 

Enviroiunent^Types . Fact^Buf f er.Package , Add.It em 

(A_Fact,  Fact^Mainager,  Fact.Pointer) ; 

—  (data-element -minimum  Name  Minimum) 

—  (data-element-minimum  Name  null) 

—  ♦♦♦♦Create  Data  Element  Maximum  Fact++^^  - 

A_Fact:=  Blank.Fact; 

A^Factd.  .20)  :=  "data- element  “maximum" ; 

A_Fact(21)  :=  »  *; 

A_Fact(22. .46)  :=  Data_Element_Record.Name ; 

A.Fact(47)  :=  *  »; 


—  This  if  then  construct  determines  what  goes  into  the  last  field. 

—  If  the  data  eleir.'^nt  maximum  is  not  null  then  create  a  fact  with  the 

—  maximum  in  it.  Flag  setting  doesn*t  matter  here. 

if  Data_Element_Record. Maximum  /= 

Data„Element_Class .Null_Data_Element_Value  then 
—  All  statements  modeled  as  0(1)  time. 

A_Fact(48. .62)  :=  Data_Element_Record. Maximum; 

else 

—  The  data  element  maximum  is  null,  so  create  a  null  fact  for 

—  either  the  .esm  file  or  the  expert  system.  Again,  the  flag 

—  setting  does  not  matter.  All  0(1)  time. 

A^Fact(48. .51)  :=  "null"; 

end  if; 

—  Store  this  fact  in  the  fact  buffer.  0(1)  time. 

Environment .Types . Fact.Buf f  er.Package . Add.Item 

(A.Fact,  Fact.Manager ,  Fact.Pointer) ; 

—  (data- element -maximum  Name  Maximum) 

—  (data-element-maximum  Name  null) 

—  ♦♦♦♦Create  Data  Element  data  range  Fact^^^^  - 

A_Fact:=  Blank.Fact; 

A_Fact(l. .23)  :=  " data- element -data-range"; 

A.Fact(24) 

A.Fact(25. .49)  :=  Data.Element_Record.Name; 

A_Fact(50) 


—  This  if  then  construct  determines  what  goes  into  the  last  field. 

—  If  the  data  element  data  range  is  not  null  then  create  a  fact  with  the 

—  range  in  it.  Flag  setting  doesn't  matter  here. 

if  Data.Element. Record. Data.Range  /=  Data.Element.Class .Null.Data.Element.Value  then 
—  All  statements  modeled  as  0(1)  time. 


B-41 


A_Fact(51. .65)  :=  Data_Elemeiit_Record.Data_Range; 
else 

—  The  data  element  data  range  is  null,  so  create  a  null  fact  for 

—  either  the  .esm  file  or  the  expert  system.  Again,  the  flag 

—  setting  does  not  matter.  All  0(1)  time. 

A_Fact(51..64)  :=  •‘null"; 

end  if; 

—  Store  this  fact  in  the  fact  buffer.  0(1)  time. 

Environment  ^Types  ,Fact3uf  f  er_Package .  Add_Item 
(A_Fact,  Fact.Manager,  Fact^Pointer) ; 

—  (data-element-data-range  Name  Data^Range) 

—  (data-element-data-range  Name  null) 


—  ♦♦♦♦Create  one  or  more  data  element  values  Facts^^^^ 


—  If  the  data  element  values  is  null  then  only  a  single  fact  is 

—  created  regardless  of  the  flag  setting. 

if  Environment .Types .Data.Buff er.Package . Is.Empty 
(Data.Element.Record . Values )  then 

—  Create  a  null  fact. 

A.Fact;=  Blank.Fact; 

A_Fact(l. .19)  :=  "data-element-values" ; 

A_Fact(20)  :=  » 

A.Fact(21 . . 45)  : =  Data.Element .Record . Name ; 

A.Fact(46)  :=  •  •; 

A_Fact(47. .50) :=  "null"; 

—  Store  this  fact  in  the  fact  buffer.  0(1)  time. 
Environment.Types.Fact.Buff er.Package. Add.Item 
(A.Fact,  Fact.Manager ,  Fact.Pointer) ; 

—  A  false  flag  setting  means  the  fact  is  for  the  expert  system. 

—  For  0.  value,  we  don’t  want  the  whole  value  in  the 

—  working  memory,  so  just  store  a  "not-null"  string* 

elsif  Type.Facts.Flag  =  False  then 
—  Create  a  fact  that  shows  the  description  is  not  null. 
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A_Fact:=  Blank.Fact; 

A_Fact(1..19)  :=  "data-eleraent-values" ; 

A.Fact(20) 

A_Fact(21 . .45)  :=  Data^Element. Record. Name; 
A.Fact(46)  :=  *  »; 

A^Fact(47..54):=  '‘not-null” ; 

—  Store  this  fact  in  the  fact  buffer.  0(1)  time. 

Environment ^Types , Fact^Buf f er.Package , Add.Item 
(A^Fact,  Fact_Manager ,  Fact^Pointer) ; 


else 

—  At  this  point  we  know  the  flag  is  true  which  means  the  fact 

—  is  to  go  to  the  .esm  file.  However,  there  may  be  multiple  lines 

—  in  the  values  thus  a  loop  is  required. 

—  Set  iterator  to  first  line  of  description. 

Environment _Types .Data^Buff er^Package. Initialize.Iterator 

(Data_Ele_Values_Iterator ,  Data_Eleraent_Record. Values) ; 

—  Engage  loop  to  get  each  line  of  the  values  and 

—  make  it  a  fact.  This  loop  is  0(x)  time  where  x  is  the 

—  number  of  lines  in  the  description. 

while  not  Environment^Types .Data_Buffer_Package.Is_Done 
(Data_Ele_Values_Iterator)  loop 

—  Retrieve  a  single  line  of  text.  0(1)  time. 
Data_Ele_Values_Line : =  Environment^Types . Data_Buf f er^Package . 

Value_Of_Item(Data_Ble-.Values_Iterator) ; 


—  Create  a  fact  representing  a  single  Jine  of  the  description. 
A_Fact:=  Blank^Fact; 

A_Fact(l . . 19)  :=  "data- element -values"; 

A^Fact(20)  :=  ’ 

A_Fact(21 . .45)  :=  Data_Element_R6Cord.Ncane; 

A^Fact(46) 

A_Fact(47. .71):=  Data_Ele_Values_Line; 

—  Store  this  fact  in  the  fact  buffer.  0(1)  time. 

Environment  „Types .  Fact^uf  f  er^Package .  Add^Item 

(A^Fact,  Fact^Manager ,  Fact_Pointer) ; 

—  Advance  pointer  by  one  to  next  line. 


Environment^Types .  Data^uf  f  er_Package . 

Get_Next(Data_Ele.Values_Iterator) ; 


end  loop; 
end  if ; 


—  (data-element-values  Name  null) 

—  (data-element-values  Name  Linel)  ... 
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—  ♦♦♦♦Create  one  or  more  Data  Element  Description  Facts^+++ 


—  If  the  data  element  description  is  null  then  only  a  single  fact  is 

—  created  regardless  of  the  flag  setting. 

if  Environment _Types . Text_Buf f er.Package . Is^Empty 
(Data_Element_Record. Descript ion)  then 

—  Create  a  null  fact. 

A.Fact:=  Blank^Fact; 

A_Fact(1..9)  :=  "data-desc'*; 

A.Fact(lO) 

A_Fact(ll . .35)  :=  Data_Element_Record.Name; 

A^Fact(36)  :=  »  »; 

A^Fact(37. .40):=  "nuir*; 

—  Store  this  fact  in  the  fact  buffer.  0(1)  time. 

Environment .Types . Fact.Buf f er.Package . Add.Item 

(A. Fact,  Fact.Manager ,  Fact.Pointer) ; 

—  A  false  flag  setting  means  the  fact  is  for  the  expert  system. 

—  For  a  description,  we  don't  want  the  whole  description  in  the 

—  working  memory,  so  just  store  a  ’’not-null’*  string! 
elsif  Type.Facts.Flag  =  False  then 

—  Create  a  fact  that  shows  the  description  is  not  null. 

A.Fact:=  Blank.Fact; 

A.Fact(1..9)  :=  "data-desc"; 

A.Fact(lO)  :=  '  '; 

A.Factdl .  .35)  :=  Data.Element.Record .  Name ; 

A.Fact(36)  :=  '  '; 

A.Fact(37.  .44):=  "not-null**; 

—  Store  this  fact  in  the  fact  buffer.  0(l)  time. 
Environment.Types .Fact.Buf ^er.Package . Add.Item 

(A.Fact,  Fact.Manager,  Fact.Pointer); 


else 

—  At  this  point  we  know  the  flag  is  true  which  means  the  fact 

—  is  to  go  to  the  .esm  file.  However,  there  may  be  multiple  lines 

—  in  the  description  thus  a  loop  is  required. 

—  Set  iterator  to  first  line  of  description. 

Environment.Types . Text.Buff er.Package . Init ialize.Iterator 

(The.Iterator ,  Data.Element.Record. Description) ; 

—  Engage  loop  to  get  each  line  of  the  description  and 

—  make  it  a  fact.  This  loop  is  0(x)  time  where  x  is  the 

—  number  of  lines  in  the  description. 

while  not  Environment.Types .Text.Buff er.Package . Is. Done 
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(The^Iterator)  loop 


—  Retrieve  a  single  line  of  text.  0(1)  time. 
A_Description«Line:=  Environment„Types.Text_Buffer_Package. 
Value.Of _Item(The_Iterator) ; 

—  Create  a  fact  representing  a  single  line  of  the  description. 
A_Fact:=  Blank^Fact; 

A„Fact(1..9)  :=  '*data-desc'’ ; 

A^Fact(lO) 

A_Fact(ll . . 35)  :=  Data^Element^Record.Name; 

A^Fact(36)  :=  *  »; 

A_Fact(37. .96) :=  A_Description_Line ; 

—  Store  this  fact  in  the  fact  buffer,  0(1)  time. 
Environment^Types  .Fact^uf  f  er^Package .  Add_Item 
(A^Fact,  Fact^Manager ,  Fact^Pointer) ; 

—  Advance  pointer  by  one  to  next  line. 

Environment ^Types .Text  ..Buf f er_Package . Get_Next (The_Iterator ) ; 
end  loop; 
end  if; 


—  (data-desc  Name  null) 

—  (data-desc  Name  not-null) 

—  (data-desc  Nsune  Description^Linel) 


—  ♦♦♦♦Create  one  or  more  data  reference  Facts^^^^ 


—  If  the  data  reference  is  null  then  only  a  single  fact  is 

—  created  regardless  of  the  flag  setting. 

if  Environment^Types .Text^Buff er^Package . Is_Empty 
(Data„Element_Record . Reference)  then 

—  Create  a  null  fact. 

A_Fact:=  Blank_Fact; 

A^Fact(1..8)  :=  "data-ref"; 

A.Fact(9)  ^ 

A_Fact(  10 . . 34)  :=  Data„Element3ecord. Name ; 

A.Fact(35)  :=  »  >; 

A^Fact(36.  .39)  :=  •'null"; 

—  Store  this  fact  in  the  fact  buffer.  0(1)  time. 

Environment ^Types .Fact^Buffer ^Package . Add_Item 

(A_Fact,  Fact.Manager ,  Fact_Pointer) ; 

—  A  false  flag  setting  means  the  fact  is  for  the  expert  system. 

—  For  a  reffirence,  we  don^t  want  the  whole  reference  in  the 

—  working  memory,  so  just  store  a  "not-null"  string' 


elsif  Type^Facts.Flag  -•  False  then 

—  Create  a  fact  that  shows  the  reference  is  not  null. 
A_Fact:=  Blank^Fact; 

A^Fact(1..8)  :=  “data-ref 

A^FactO)  :=  »  »; 

A_Fact(10. .34)  :=  Data_Element_Record.Name; 

A.Fact(36)  ^ 

A_Fact(36. .43):=  “not-null"; 

—  Store  this  fact  in  the  fact  buffer.  0(1)  time. 
Environment .Types . Fact.Buf f er.Package . Add.Item 
(A.Fact,  Fact . Manager ,  Fact.Pointer) ; 


else 

—  At  this  point  we  know  the  flag  is  true  which  means  the  fact 

—  is  to  go  to  the  .esm  file.  However,  there  may  be  multiple  lines 

—  in  the  reference  thus  a  loop  is  required. 

—  Set  iterator  to  first  line  of  description. 

Environment .Types .Text. Buff er. Package . Initialize. Iterator 

(Ref erence.Iterator ,  Data.Element.Record, Ref erence) ; 

—  Engage  loop  to  get  each  line  of  the  reference  and 

—  make  it  a  fact.  This  loop  is  0(x)  time  where  x  is  the 

—  number  of  lines  in  the  reference. 

while  not  Environment .Types .Text. Buff er.Package . Is.Done 
(Reference.Iterator)  loop 

—  Retrieve  a  single  line  of  text.  0(1)  time. 

A.Ref erence.Line : =  Environment .Types .Text.Buff er.Package . 

Value_Of.Item(Ref erence.Iterator) ; 

—  Create  a  fact  representing  a  single  line  of  the  description. 
A.Fact:=  Blank.Fact; 

A.Fact(1..8)  :=  '*data-ref  ” ; 

A.Fact(9)  :=  »  ^ 

A.FactdO.  .34)  :=  Data.Element.Record. Name; 

A.Fact(35)  :=  »  »; 

A.Fact (36 . . 95) : =  A.Ref erence.Line ; 

—  Store  this  fact  in  the  fact  buffer.  0(1)  time. 

Environment .Types . Fact.Buff er.Package . Add.Item 
(A.Fact,  Fact.Manager ,  Fact.Pointer) ; 

—  Advance  pointer  by  one  to  next  line. 

Environment.Types. Text.Buff er.Package. Get .Next (Ref erence.Iterator) ; 
end  loop; 
end  if; 


—  (data-ref  Name  not-null) 
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—  (data-rel  Name  null) 

—  (data-rel  Name  Reference^Linel) 

—  t)|c4c4c4c]ftt](e%  Create  data  reference  type  facts  120390 

A^Fact  :=  Blank^Fact; 

A_Fact(l . .  13)  :=  *'data~ref“type" ; 

A_Fact(14)  :=  ^ 

A_Fact(15. .39)  :=  Data_Element_Record.Name; 

A_Fact(40)  :=  '  *; 

if  Data_Element_Record.Reference.Type  /= 

Environment .Types . Null_Reference_Type  then 
A_Fact(41. .65)  :=  Data_Eleraent_Record.Ref erence.Type; 


else 

A_Fact(41. .44)  :=  “null"; 
end  if; 

Environment .Types . Fact.Buf f er.Package . Add.Item 
(A.Fact,  Fact .Manager,  Fact.Pointer) ; 

—  (data-ref“type  Name  Ref erence.Type)  or 

—  (data-ref“type  Name  null) 


— .  Create  data  element  Version  facts 

A.Fact  :=  Blank.Fact; 

A.Fact (1 .. 12)  :=  “data-ele-ver" ; 

A.Fact(13)  :=  »  *; 

A.Fact (14.  .38)  :=  Data.Eleraent.Record.Ncime; 

A.Fact (39) 

if  Data.Element.Record. Vers ion  /= 

Data.Element.Class .Null.Data.Element.Version.number  then 
A.Fact (40. .49)  :=  Data.Element.Record. Version; 


else 

A.Fact (40. .43)  :=  “null"; 
end  if; 

Environment .Types . Fact.Buf f er.Package . Add.Item 
(A.Fact,  Fact.Hanager,  Fact.Pointer); 

—  (data-ele-ver  Name  Data-Element-Version)  or 

—  (data-ele-ver  Name  null) 

—  ♦♦♦  Create  one  or  more  data  element  Version-Changes  facts  — 
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—  if  the  data  element  version  changes  is  null  then  only  a  single 

—  fact  is  created  regardless  of  the  flag  setting 


if  Environment .Types . Text.Buf f er.package . Is.Empty 

(Data.Element .Record .  Version.Changes  )  then 
—  true  it  is  empty 


A.Fact 

A.Fact(1..12) 
A.Fact (13) 
A_Fact(14. .38) 
A.Fact (39) 
A.Fact(40. .43) 


=  Blank.Fact; 

=  "data-e-v-chg" ; 

”  » 

=  Data.Element.Record.Name; 

~  I  ) . 

I 

=  “null”; 


Environment.Types . Fact.Buf fer.Package . Add.Item 
(A.Fact,  Fact.Manager ,  Fact.Pointer) 


elsif  Type. Facts. Flag  =  false  then 

A.Fact  :=  Blank.Fact; 

A.Factd .  .  12)  :=  "data-e-v-chg” ; 

A.Fact(13)  ^ 

A.Fact ( 14. . 38)  :=  Data.Element.Record.Name; 
A.Fact(39)  ^ 

A.Fact (40.  .47)  :=  “not-null”;' 

Environment.Types . Fact.Buf fer.Package . Add.Item 
(A.Fact,  Fact.Manager ,  Fact.Pointer); 


else  —  version  not  empty  show  the  version  changes  to  .esm  — 

Environment.Types . Text.Buf fer.Package . Init ialize.Iterator 
(Version.Iterator ,  Data.Element. Record. Version.Changes) ; 

—  Engage  a  loop  to  get  each  version  of  changes  and  make  it  a  fact 

while  not  Environment.Types .Text. Buff er.Package. Is.Done 
(Version.Iterator)  loop 

Version.Line  := 

Environment.Types .Text. Buff er.Package .Value. Of. Item(Version. Iterator) ; 


A.Fact  :=  Blank.Fact; 

A.Fact( 1 . . 12)  :=  "data-e-v-chg" ; 

A_Fact(13)  ^ 

A.Fact(14. .38)  :=  Data.Element.Record.Name; 
A.Fact(39)  ^  ^ 
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A_Fact(40. .99)  :=  Version.Line; 


—  (data-e-v~chg  Name  null) 

—  (data-e-v-chg  Name  not-null) 

—  (data-e-v-chg  Name  Version-changes) 
Environment ^Types . Fact^Bulf er^Package . Add.Item 

(A.Fact,  Fact^Manager,  Fact^Pointer) ; 

Environment«Types.Text_Bulfer_Package.Get_Next(Version_Iterator) ; 


end  loop; 
end  if; 


—  ♦♦♦♦Create  data  element  Date  Fact  - 

A_Fact:=  Blaink^Fact; 

A_Fact(l . . 13)  :=  "data-ele-date”; 

A„Fact(14)  :=  ’  *; 

A_Fact(16. .39)  :=  Data.Element_Record.Name; 

A_Fact(40)  ^ 

if  Data_Element_Record.Date  /=  Environment.Types.Null.Date  then 
A.Fact(41 . .48)  :=  Data.Element.Record.Date; 

else 


A.Fact(41.  .44)  :=  '‘null*'; 
end  if; 


—  Store  this  date  fact  in  the  fact  buffer.  0(1)  time. 

Environment .Types . Fact.Buf f  er.Package . Add.Item 

(A.Fact,  Fact.Manager ,  Fact. Pointer) ; 

—  (date-ele-date  Naune  mm/dd/yy) 

—  (data-ele-date  Name  null) 

—  ♦♦♦♦Create  data  element  Author  Fact**** - 

A.Fact :=  Blank.Fact; 

A.Factd . .  16)  :=  *’data-ele-author” ; 

A.Fact (16)  ^ 

A.Fact(17. .41)  :=  Data.Element_Record.Name; 

A.Fact (42) 

—  This  if  then  construct  determines  what  goes  into  the  last  field. 

—  If  the  data  element  author  is  not  null  then  create  a  fact  with  the 

—  data  element  author  in  it.  Flag  setting  doesn't  matter  here. 

if  Data.Element. Record. Author  /=  Environment .Types .Null.Author.Name  then 

—  All  statements  modeled  as  0(1)  time. 

A.Fact (43. .67)  :=  Data.Element.Record. Author ; 

else 

—  The  data  element  author  is  null,  so  create  a  null  fact  for 
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—  either  the  .esra  file  or  the  expert  system.  Again,  the  flag 

—  setting  does  not  matter.  All  0(1)  time. 

A_Fact(43..46)  :=  "null”; 

end  if; 

—  Store  this  fact  in  the  fact  buffer.  0(1)  time. 

Environment ^Types . Fact^Buf f  er^Package . Add^It em 
(A^Fact,  Fact^Manager ,  Fact^Pointer) ; 

—  (data-ele-author  Name  Author) 

—  (data-ele-author  Name  null) 


Data_Element„Manager . Advance_Iterator_To_Next_Data_Element ; 
end  loop; 

end  Retrieve^Data^Element^Facts; 


—  DATE:  2/21/91 

—  VERSION:  1.0 

—  NAME:  ♦♦♦PROCEDURE  RESTORE  DATA  ELEMENT  FACTS^^^ 

—  MODULE  NUMBER:  TBD 

—  DESCRIPTION:  This  procedure  accepts  a  buffer  of  data  element  facts  — 

—  and  restores  that  information  into  the  data  element  manager.  Of 

—  special  note  is  that  the  procedure  assumes  the  facts  are  in  the 

—  same  order  in  which  they  were  stored. 

—  ALGORITHM:  A  single  while  loop  controls  the  execution  with  an 

—  embedded  call  to  an  0(i)  procedure. 

—  PASSED  VARIABLES:  The_Fact_Buf f er  (contains  the  facts) 

—  RETURNS:  None 

—  GLOBAL  VARIABLES  USED:  None 

—  GLOBAL  VARIABLES  CHANGED:  None 

—  FILES  READ:  None 

—  FILES  WRITTEN:  None 

—  HARDWARE  INPUT:  None 

—  HARDWARE  OUTPUT:  None 

—  MODULES  CALLED:  None 

—  CALLING  MODULES:  Essential^IO. Restore^Project 

—  ORDER-OF:  order  of  is  0(a  ♦  max  (x,  z  ♦  (a  ♦  z)))  where  a  is  the  — 

—  number  of  data  elements,  x  is  the  number  of  lines  in  a  description  — 

—  and  z  is  the  number  of  reference  that  a  data  element  has.  Note 

—  that  this  order  of  may  change  when  more  of  the  data  element 

—  manager  facts  are  restored. 

—  Note  that  all  string  slice  operations  are  modeled  as  0(1)  time. 

—  AUTHOR(S) :  Min-fuh  Shyong 

—  HISTORY:  none  (Initial  Implementation) 


B-r)0 


procedure  Restore^Data.Element .Facts 
(The.Fact .Buffer  :  in 

Environment .Types . Fact.Buf f er.Package . Manager. Type)  is 

—  Local  Declarations  — 

Fact.Pointer :  Environment .Types .Fact.Buf f er.Package. It erator.Type ; 
A.Fact :  Environment .Types . Fact.String.Type ; 

First.Char:  natural :=  0; 

Char.Position:  natural :=  0; 

Temp.Pos:  natural :=  0; 

More.Descriptions.Flag:  boolean; 

—  Data  Element  Related  Declarations  — 

Data.Eleraent.Record :  Data.Element.Class . Data.Element.Record.Type ; 
Data.Element. Pointer :  Data.Element.Mamager . Data.Element.Pointer.Type ; 
Null.Data.Element.Record :  Data.Element.Class . Data.Element.Record.Type ; 

The.Iterator :  Environment.Types . Text.Buff er.Package . It erator.Type ; 

Data. Sle.Values.Line  :  Environment.Types .DD.Field.Type ; 

A.Description.Line  :  Environment.Types .DD.Text.Type ; 

A.Reference.Line  :  Environment.Types .DD.Text.Type; 

Version.Line  :  Environment.Types .DD.Text.Type ; 


Found.Flag:  boolean :=  False; 

Result.Flag:  boolean; 

—  Exception  — 

—  This  exception  is  declared  here  because  the  Essential  10  package  does 
—  not  check  to  see  the  facts  are  in  any  specific  order. 

Invalid.Fact.Sequence.For .Data.Element :  exception; 

Data.Element. Hierarchy.Error.During.Rest ore :  exception; 


—  -  begin  Restore  Data  Element  - 

begin 

—  Check  for  empty  buffer  of  facts.  If  empty,  do  nothing. 

if  Environment.Types . Fact .Buff er.Package. Is. Empty (The.Fact. Buffer)  then 
return; 
end  if; 

—  Initialize  iterator  to  first  fact. 

Environment.Types . Fact.Buf f er.Package . Initialize.Iterator 
(Fact.Pointer,  The.Fact.Buf f er) ; 

—  Engage  loop  to  extract  the  data  element  facts  from  a  buffer 
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““  one  at  a  time.  This  loop  will  execute  a  times  —  once  for 

—  each  data  element.  Note  that  there  are  many  facts  associated  with 

—  a  single  data  element.  This  loop  runs  a  times.  The  loop  has  one 

—  inner  loop  of  order  x  and  one  procedure  call  of  (a  *  z).  Thus, 

—  order  of  is  0(a  ♦  max  (x,  z*{  a  ♦  z)  )  ) 

While  not  Environment_Types.Fact_Buffer_Package.Is_Done(Fact_Pointer)  loop 

—  Get  a  record. 

A^Fact :  =  Environment  _Types .  Fact3uf  f  er^Package .  Value^Of  _Item 
(Fact.Pointer) ; 

—  Since  we  put  the  information  in  the  string,  we  know  the 

—  exact  columns  where  information  should  be. 

—  All  string  assignments  are  modeled  as  0(1); 

—  Insure  the  fields  are  all  blanks. 

Data^Element ^Record : =  Null.Dat a_Element_Record ; 


—  Restore  Data  Element  Naone  ♦**  - 

—  The  first  fact  should  be  the  name. 

if  A_Fact(l. . 17)  /=  "data-element-name"  then 
Text.IO . Put_Line(A^Fact) ; 

Text_IO.Put_Line(**I  am  I  ^p:  data-element-name .  "); 

raise  Invalid^Fact_Sequence_For_Data„Element ; 
end  if; 

—  The  Data  Element  name  must  be  in  columns  19  through  43. 

Dat a^Element ^Record . Name : =  A_Fact ( 19 . . 43 ) ; 

—  Check  to  see  if  Data  Element  already  exists.  0(a)  call. 
Data^Element^Manager .Data_Element_Exists (Data. Element.Record . Name , 

D at a.Element. Pointer,  Found.Flag) ; 

if  Found.Flag  =  False  then 

—  Do  0(a  *  z)  procedure  call  to  create  a  data  element. 
Data.Element .Manager . Create.Data.Element 

(Data.Element.Record . Name ,  Data.Element.Pointer ) ; 
end  if; 

—  Advance  pointer  to  next  fact  in  manager.  0(1). 

Environment .Types . Fact.Buf f er.Package . Get.Next (Fact.Pointer ) ; 

—  Get  a  fact.  0(1)  time. 

A.Fact : =  Environment. Types . Fact.Buf f  er.Package . Value.0f.lt em 
(Fact.Pointer) ; 


—  Restore  Data  Element  Data  Type  *** - 

—  This  fact  should  be  the  Data  Element  Data  Type. 
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if  A_Fact(l. . 17)  /=  "data-element-type"  then 
Textile. Put _Line(A_Fact) ; 

Text_IO.Put_Line("I  am  Exp:  data-element-type.  "); 
raise  Invalid_Fact_Sequence_For_Data_Element ; 
end  if; 

—  Columns  19  through  43  must  be  the  same  data  element  name, 
if  A„Fact(19. .43)  /=  Data.Element .Record. Name  then 

Text.IO . Put.Line( A.Fact ) ; 

Text.IO.Put.LineC'I  am  Exp:  data-element-type.Naroe.  ”); 
raise  Invalid.Fact_Sequence_For.Data.Element ; 
end  if; 

—  Columns  45  through  69  hold  the  data  element  data  type  if  it  is 

—  not  null. 

if  A.Fact(45.  .48)  =  ’’null'’  then 

—  Do  nothing,  there  was  no  data  element  data  type, 
null; 
else 

—  Get  the  number., 

Data.Eleroent.Record.Data_Type:=  A.Fact(45. .69) ; 

—  Do  0(1)  procedure  call  to  update  the  data  type  in  the  data  element 
—  manager. 

Data.Element .Manager . Set_Data.Element.Data_Type 

(Data_Element_Point er ,  Data.Element. Record . Data.Type) ; 
end  if ; 

—  Advance  pointer  to  next  fact  in  manager. 

Environment .Types .Fact.Buff er.Package. Get. Next (Fact.Po inter) ; 

—  If  the  fact  buffer  is  empty  at  this  point  there  is  an  error 

—  in  the  format. 

if  Environment .Types . Fact.Buff er.Package . Is.Done(Fact. Pointer )  then 
Text.IO.Put.Line(A.Fact) ; 

Text.IO.Put.LineC'I  am  Exp:  data-element-type.Is.Done  "); 
raise  Invalid.Fact.Sequence.For.Data.Element ; 
end  if; 

—  Get  a  fact. 

A.Fact :=  Environment .Types .Fact.Buff er.Package .Value.Of .Item 
(Fact.Pointer) ; 

—  Restore  Data  Element  Minimum  ♦♦♦  - 

—  This  fact  should  be  the  Data  Element  Minimum. 

if  A.Fact (1 . .20)  /=  "data-element-minimum"  then 
Text.IO.Put.Line(A.Fact) ; 

Text.IO.Put.Line("I  am  Exp:  data-element-minimum.  ”); 

raise  Invalid.Fact.Sequence.For.Data.Element ; 
end  if ; 
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—  Colimns  22  through  46  roust  be  the  same  data  element  name, 
if  A_Fact(22. .46)  /=  Data_Element_Record . Name  then 

Text.IO.Put_Line(A_Fact) ; 

Text^IO.Put_Line('*I  am  Exp:  data-element-roinirauro.Name.  "); 
raise  Invalid_Fact_Sequence_For_Data_Element ; 
end  if ; 

—  Columns  48  through  62  hold  the  data  element  minimum  if  it  is 

—  not  null. 

if  A^Fact(48. .51)  =  "null"  then 

—  Do  nothing,  there  was  no  data  element  minimum, 
null; 

else 

—  Get  the  minimum. 

Data_Element_Record . Minimum : =  A_Fact (48 . . 62 ) ; 

—  Do  0(1)  procedure  call  to  update  the  minimum  in  the  data  element 

—  manager. 

Data_Element_Maaiager . Set_Data_Element„Minimum 

(Data^Element.Pointer ,  Data_Element_Record. Minimum) ; 
end  if ; 

—  Advance  pointer  to  next  fact  in  manager. 

Environment ^Types .Fact_Buff er_Package .Get_Next(Fact_Pointer) ; 

—  If  the  fact  buffer  is  empty  at  this  point  there  is  an  error 

—  in  the  format. 

if  Environment _Types .Fact_Buffer_Package.Is_Done(Fact_Pointer)  then 
Text_IO.Put_Line(A_Fact) ; 

Text_IO.Put_Line("I  am  Exp:  data-element -minimum. Is^Done .  "); 

raise  Invalid„Fact_Sequence_For_Data_Element ; 
end  if ; 

—  Get  a  fact. 

A^Fact :=  Environment _Types.Fact_Buffer_Package.Value_Of„Item 
(Fact.Pointer) ; 


—  Restore  Data  Element  Maximum  ♦♦♦ - 

—  This  fact  should  be  the  Data  Element  Maximum. 

if  A_Fact(l . .20)  /=  "data-element-maximum"  then 
Text„IO.Put.Line(A.Fact) ; 

Text_IO.Put_Line("I  am  Exp:  data- element -maximum  "); 

raise  Invalid_Fact„Sequence_For_Data_Element ; 
end  if ; 

—  Columns  22  through  46  must  be  the  same  data  element  name, 
if  A_Fact(22. .46)  /=  Data.El ement. Record . Name  then 


Text_IO.Put„Line(A_Fact) ; 

Text_IO.Put„Line(“I  am  Exp:  data-element-maximum.Name.  *') 
raise  Invalid„Fact_Sequence_For_Data_Eleraent ; 
end  if; 

—  Columns  48  through  62  hold  the  data  element  maximum  if  it  is 

—  not  null. 

if  A_Fact(48.  .51)  =  •’null"  then 

—  Do  nothing,  there  was  no  data  element  maximum, 
null; 
else 

—  Get  the  maximum. 

Dat a^Element.Re cord. Maximum :=  A_Fact(48. .62); 

—  Do  0(1)  procedure  call  to  update  the  maximum  in  the  data  element 
—  manager. 

Data_Element_Manager . Set_Data_Element_Maximum 

(Data_Element_Pointer ,  Dat a,Element_Record . Maximum) ; 
end  if; 

—  Advance  pointer  to  next  fact  in  manager. 

Environment _Types . Fact^Buf f er^Package . Get^Next (Fact^Pointer) ; 

—  If  the  fact  buffer  is  empty  at  this  point  there  is  an  error 

—  in  the  format. 

if  Environment _Types .Fact^Buff er^Package. Is„Done(Fact_Pointer)  then 
Text_IO.Put_Line(A_Fact) ; 

Text_IO.Put_Line("I  am  Exp:  data-element-maximum.Is_done.  "); 
raise  Invalid_Fact_Sequence_For_Data_Elemen^ ; 
end  if ; 

—  Get  a  fact. 

A.Fact : =  Environment .Types . Fact.Buf f  er.Package . Value.Of .Item 
(Fact.Pointer) ; 

—  Restore  Data  Element  Data  Range  - 

—  This  fact  should  be  the  Data  Element  Data  range. 

if  A.Fact(l .  .23)  /=  “data-eleraent-data-range*'  then 
Text. 10 . Put. Line (A.Fact ) ; 

Text.IO.Put.Line(*'I  am  Exp:  data-element-data-range.  "); 
raise  Invalid.Fact.Sequence.For.Data.Element ; 
end  if; 

—  Columns  26  through  49  must  be  the  same  data  element  name, 
if  A_Fact(25. .49)  /=  Data.Element. Record. Name  then 

Text. 10. Put. Line(A_Fact) ; 

Text. 10.  Put  .Line  (**I  am  Exp:  data-element-data-range .  Name  "); 

raise  Invalid.Fact.Sequence.For.Data.Element : 
end  if; 
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—  Columns  61  through  65  hold  the  data  element  data  range  if  it  is 

—  not  null. 

if  A_Fact(61..54)  =  ”null”  then 

—  Do  nothing,  there  was  no  data  element  data  range, 
null; 

else 

—  Get  the  range. 

Data_Element_Record.Data_Range:=  A_Fact(51. .65); 

—  Do  0(1)  procedure  call  to  update  the  data  range  in  the  data  element 

—  manager. 

Data_Element_Manager .  Set_Data_Element_Data_Range 

(Data^Element^Pointer,  Data_Element_Record.Data_Range) ; 
end  if; 

—  Advance  pointer  to  next  fact  in  manager.  - 

Environment _Types .Fact_Buffer_Package.Get_Next(Fact_Pointer) ; 

—  If  the  fact  buffer  is  empty  at  this  point  there  is  an  error 

—  in  the  format. 

if  Environment ^Types  .Fact^Buffer^Package .  Is_Done(Fact_Pointer )  then 
Text_I0. Put .Line (A.Fact) ; 

Text.IO.Put_Line(*'I  am  Exp:  data-element-data-rainge.Is.Done. 
raise  Invalid_Fact.Sequence_For.Data.Element ; 
end  if; 

—  Get  a  fact. 

A.Fact : =  Environment .Types . Fact.Buf f er.Package . Value.Of .Item 
(Fact.Pointer) ; 


—  ♦♦♦  Restore  Data  Element  Values  facts  - 

if  A.Factd  .  .  19)  /=  "data-element- values”  then 
Text_IO.Put.Line(A.Fact) ; 

Text_IO.Put.Line(”I  am  Exp:  data-element-values .  ”); 

raise  Invalid.Fact.Sequence.For.Data.Element ; 
end  if; 

—  Columns  21  through  45  must  be  the  same  data  element  name, 
if  A.Fact(21 . .45)  /=  Data.Element.Record.Name  then 

Text. 10 . Put.Line( A.Fact ) ; 

Text.IO.Put_Line(”I  am  Exp:  data-element-values.Name.  ”); 
raise  Invalid.Fact.Sequence.For.Data.Element ; 
end  if; 

—  If  the  values  list  is  null  then  we  are  done  with  this  attribute. 

—  Need  only  to  advance  the  pointer  by  one  for  the  outer  loop. 


if  A^Fact(47.  .50)  =  ''null"  then 

—  There  is  no  values  list  for  the  data  element,  so  just  advance 

—  the  fact  pointer. 

—  Advance  pointer  to  next  fact  in  manager.  0(1)  time. 
Environment .Types . Fact. Buff  er.Package . Get. Next (Fact. Point er) ; 

else 

—  There  must  be  one  or  more  values. 

—  This  loop  will  run  z  times  where  z  is  the  number  of  values. 


while  A.Fact(l. .19)  =  "data-element-values"  loop 

—  Columns  21  through  45  must  be  the  same  data  element  name. 

—  0(1)  time  complexity. 

if  A.Fact(21 . .45)  /=  Data.Element.Record. Name  then 
Text. 10 . Put .Line ( A.Fact ) ; 

Text.IO.Put.Line("I  am  Exp:  data-element-values .Name,  in  while 
raise  Invalid.Fact.Sequence.For.Data.Element; 
end  if; 

—  Pull  a  Value  from  the  fact. 

Data.Ele.Values.Line:=  A.Fact (47. ,71) ; 

—  In  order  to  add  a  value,  the  Data  Element  Manager 

—  requires  that  the  value  already  exist  as  a  data  element. 

—  Thus,  must  create  the  data  element  first  if  needed. 

—  Check  to  see  if  data  element  already  exists,  0(a)  call. 
Data.Element .Mainager . Data.Element. Exists (Data_Ele.Values.Line , 
Data.Element.Pointer,  Found.Flag) ; 
if  Found.Flag  =  False  then 

—  Do  0(a  *  z)  procedure  call  to  create  a  data  element. 
Data.Element.Meinager .  Create.Data.Element 

(Data_Ele_Values_Line,  Data.Element.Pointer) ; 
end  if ; 

—  Do  another  0(a  ♦  z)  procedure  call  to  add  this  data  element 


Data.Element. Manager . Set.Data.Element .Values 

(Data.Element.Pointer,  Data.Element.Record. Values) ; 


—  Must  now  call  Data  Element  Exists  again  in  order  to  reset  the 
—  pointer  for  any  future  operations.  0(a)  time. 

Data.Element. Manager . Data.Element.Exists (Data.Element.Record . Name , 
Data.Element.Pointer,  Found.Flag) ; 


—  Aa’;ance  pointer  to  next  fact  in  manager. 

Environment ^Types .Fact_Buff er_Package.Get_Next (Fact .Pointer) ; 

—  If  it  is  not  empty  get  the  next  fact.  0(1)  time, 
if  not  Environment _Types . Fact. Buffer .Package . Is. Done 
(Fact.Pointer)  then 

A.Fact : =  Enviroiunent .Types . Fact.Buf f er.Package . Value.0f.lt em 
(Fact.Pointer) ; 

else 

Text. 10. Put .Line (A.Fact) ; 

Text.IO,Put_Line("I  am  Exp:  data-element-values  in  else  "); 
raise  Invalid.Fact.Sequence.For.Data.Element ; 
end  if; 
end  loop; 
end  if; 

—  Restore  Data  Element  Description  Facts  ***  - 


if  Environment .Types . Fact.Buf f er.Package . Is.Done(Fact.Pointer)  then 
Text.IO . Put .Line (A.Fact ) ; 

Text.IO.Put.LineC'I  am  Exception:  data-element  Is.Done  "); 
raise  Invalid.Fact. Sequence. For.Data.Element ; 
end  if; 

A.Fact : =  Environment .Types . Fact.Buf f  er.Package . Value.Of .It em 
(Fact.Pointer) ; 


—  The  series  of  fact(s)  should  be  the  data  element  description. 

—  There  is  at  least  one  data-desc  fact  and  possible  more, 
if  A.Fact(1..9)  /=  "data-desc"  then 

Text. 10. Put .Line (A.Fact) ; 

Text.IO.Put.Line("I  eim  Exp:  data-desc,  "); 
raise  Invalid.Fact. Sequence.For.Data.Element ; 
end  if; 

—  Columns  11  through  35  must  be  the  same  data  element  name, 
if  A.Factdl .  .35)  /=  Data.Element. Record. Name  then 

Text.IO . Put.Line(A.Fact ) ; 

Text.IO . Put .Line("I  am  Exp:  data-desc .Name  "); 
raise  Invalid.Fact. Sequence.For.Data.Element ; 
end  if ; 

—  If  the  description  is  null  then  we  are  done  with  this  attribute. 

—  Need  only  to  advance  the  pointer  by  one  for  the  outer  loop, 
if  A.Fact(37. .40)  =  "null"  then 

—  There  is  no  description  for  the  data  element,  so  just  advance 

—  the  fact  pointer. 

—  Advance  pointer  to  next  fact  in  manager.  0(1)  time. 
Environment.Types . Fact. Buff er.Package . Get. Next{Fact. Pointer) ; 


else 

—  There  must  be  one  or  more  lines  in  the  description, 

—  This  loop  will  run  x  times  where  x  is  the  number  of  lines  in  the 

—  description. 

while  A_Fact(1..9)  =  "data-desc"  loop 

—  I  realize  this  check  is  repetitive  on  the  first  iteration. 

—  Columns  11  through  35  must  be  the  same  data  element  name. 

—  0(1)  time  complexity, 

if  A_Fact(ll .  .35)  /=  Data^Element^ecord.Name  then 
Text.IO .Put_Line(A_Fact) ; 

Text^IO.Put_Line("I  am  Exp:  data-desc.Name  in  while  "); 
raise  Invalid_Fact_Sequence_For_Data_Element ; 
end  if; 

—  Pull  the  description  from  the  fact. 

A_Description_Line:=  A_Fact(37. .96); 

—  Add  the  description  to  the  description  part  of  the 

—  data  element  record.  0(1)  time. 

Enviroiment.Types .Text_Buf fer .Package, Add_Item 

(A.Description.Line,  Data.Element.Record, Descript ion,  The.Iterator) ; 

—  AdvcOice  pointer  to  next  fact  in  mcinager, 

Environment.Types . Fact.Buf f er.Package . Get.Next (Fact.Pointer ) ; 

—  If  it  is  not  empty  get  the  next  fact.  0(1)  time, 
if  not  Environment.Types .Fact.Buf f er.Package . Is.Done 
(Fact. Pointer)  then 

A_Fact:=  Environment .Types . Fact _Buf f er.Package .Value.Of. Item 
(Fact.Pointer) ; 

else 

—  If  this  is  the  last  fact  of  the  last  data  element  exit  the 
—  loop. 

Text. 10 . Put.Line(A.Fact ) ; 

Text.IO.Put.Line("I  am  Exp:  data-desc  in  else  "); 
raise  Invalid.Fact.Sequence.For.Data.Element ; 
end  if; 
end  loop; 

—  There  were  one  or  more  lines  in  the  description  so  now  must 

—  place  them  with  the  data  element  in  the  data  element  manager.  0(1). 
Data.Element.Manager . Set. Data.Element .Description 

(Data.Element.Pointer ,  Data.Element. Record. Descript ion) ; 

end  if; 

—  If  the  fact  buffer  is  empty  at  this  point  there  is  an  error 

—  in  the  format.  0(1)  time.  I  know  this  because 

—  Retrieve.Data.Element.Facts  will  at  least  put  a  null  entry 
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if  Environment  .Types.  Fact  _Bufler_Package.  Is_Done(Fact_Pointer)  then 
Text.IO. Put. Line (A.Fact) ; 

Text. 10.  Put  .Line  ('*  I  am  Exp:  data-desc.Is.Done 
raise  Invalid.Fact.Sequence.For.Data.Element ; 
end  if; 

—  Get  a  fact. 

A.Fact : =  Environment .Types . Fact.Buf f er.Package . Value.Of .Item 
(Fact .Pointer) ; 

—  The  series  of  fact(s)  should  be  the  data  element  description. 

—  There  is  at  least  one  data-desc  fact  and  possible  more. 


—  Restore  Data  Element  Reference  Facts  - 

if  Environment .Types. Fact.Buff er.Package. Is.Done(Fact.Pointer)  then 
Text.IO.Put_Line(A.Fact) ; 

Text.IO.Put.Line("I  am  Exp:  data-ref . Is.Done.  *'); 

raise  Invalid.Fact.Sequence.For.Data.Element ; 
end  if; 

Get  a  fact. 

A.Fact :=  Environment .Types .Fact.Buff er.Package .Value.Of .Item 
(Fact.Pointer) ; 


—  The  series  of  fact(s)  should  be  the  Data  Element  Reference. 

—  There  is  at  least  one  data-ref  fact  and  possible  more, 
if  A_Fact(1..8)  /=  "data-ref*‘  then 

Text. 10 . Put.LineC A.Fact) ; 

Text_IO.Put.Line("I  am  Exp:  data-ref.  ’*); 
raise  Invalid.Fact.Sequence.For.Data.Element ; 
end  if; 

—  Columns  10  through  34  must  be  the  same  data  element  name, 
if  A_Fact(10. . 34)  /=  Data.Element. Record. Name  then 

Text. 10 . Put.Line (A.Fact) ; 

Text_I0.Put.Line("I  am  Exp:  data-ref . Name  '*); 
raise  Invalid.Fact.Sequence.For .Data.Element ; 
end  if; 

—  If  the  Reference  is  null  then  we  are  done  with  this  attribute. 

—  Need  only  to  advance  the  pointer  by  one  for  the  outer  loop. 

if  A.Fact(36. . 39)  =  "null**  then 

—  There  is  no  reference  for  the  data  element,  so  just  advance 

—  the  fact  pointer. 

—  Advance  pointer  to  next  fact  in  manager.  0(1)  time. 
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Environment ^Types . Fact_Buf 1 er^Package . Get^Next (Fact^Point er) ; 
else 

—  There  must  be  one  or  more  lines  in  the  reference. 

—  This  loop  will  run  x  times  where  x  is  the  number  of  lines  in  the 

—  reference. 

while  A_Fact(1..8)  =  **data-ref*'  loop 

—  I  realize  this  check  is  repetitive  on  the  first  iteration. 

—  Columns  10  through  34  must  be  the  same  data  element  name. 

—  0(1)  time  complexity. 

if  A_Fact(10, .34)  /=  Data_Element_Record.Name  then 
Text^IO, Put .Line (A^Fact) ; 

Text.IO.Put.Line(*'I  am  Exp:  data-ref . Name  in  while  *'); 
raise  Invalid.Fact.Sequence.For.Data.Element ; 
end  if; 

—  Pull  the  reference  from  the  fact. 

A.Ref erence.Line:=  A.Fact(36. .95); 

—  Add  the  reference  to  the  reference  part  of  the 

—  data  element  record.  0(1)  time. 

Environment .Types .Text.Buff er.Package. Add.Item 

(A.Ref erence.Line,  Dat a.Element .Record. Ref erence,  The.Iterator) 

—  Advance  pointer  to  next  fact  in  manager. 

Environment .Types. Fact .Buff er.Package. Get.Next(Fact.Pointer) ; 

—  If  it  is  not  empty  get  the  next  fact.  0(1)  time. 

if  not  Environment .Types. Fact.Buff er.Package. Is.Done 
(Fact.Pointer)  then 

A.Fact : =  Environment .Types .Fact.Buff er.Package . Value.Of .Item 
(Fact.Pointer) ; 

else 

—  If  this  is  the  last  fact  of  the  last  data  element  exit  the 
—  loop. 

Text. 10 . Put.Line (A.Fact ) ; 

Text.I0.Put_Line(‘'I  am  Exp:  data-ref.  in  else  ’*); 
raise  Invalid.Fact.Sequence.For.Data.Element ; 
end  if; 
end  loop; 

—  There  were  one  or  more  lines  in  the  reference  so  now  must 

—  place  them  with  the  data  element  in  the  data  element  manager.  0(1) 
Data.Element .Manager . Set.Data.Element.Ref erence 

(Data.Element.Pointer ,  Data.Element.Record. Ref erence) ; 

end  if ; 
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—  ♦♦♦  Restore  Data  Element  Reference  Type  Facts  - 

if  Environment .Types .Fact„Buffer_Package . Is.Done(Fact_Pointer)  then 
Text.IO.Put.Line(A.Fact) ; 

Text.IO.Put.LineC’I  am  Exception:  data-element  reference  type  Is.Done  ") 
raise  Invalid.Fact.Sequence.For.Data.Element ; 
end  if; 

—  Advance  pointer  to  next  fact  in  manager.  0(1). 

— Environment .Types. Fact.Buffer.Package.Get.Next (Fact .Pointer) ; 


—  Get  a  fact.  0(1)  time. 

A.Fact : =  Environment .Types . Fact.Buf f er.Package . Value.Of .Item 
(Fact.Pointer) ; 

—  This  fact  should  be  the  Data  Element  Reference  Type, 
if  A.Factd . .  13)  /=  “data-ref-type'*  then 

Text. 10. Put .Line (A.Fact) ; 

Text.IO.Put.Line(‘'I  am  Exp;  data-ref -type .  "); 

raise  Invalid.Fact.Sequence.For.Data.Element ; 
end  if; 

—  Columns  15  through  39  must  be  the  same  data  element  name, 
if  A.Fact (15. .39)  /=  Data.Element.Record, Name  then 

Text.IO.Put.Line(A.Fact) ; 

Text.IO.Put.Line("I  am  Exp:  data-ref-type .Name  “); 
raise  Invalid.Fact.Soquence.For.Data.Element ; 
end  if; 

—  Columns  41  through  65  hold  the  Data  Element  Reference  Type  if  it  is 

—  not  null. 

if  A.Fact(41 . .44)  =  “null"  then 

—  Do  nothing,  there  was  no  Data  Element  Reference  Type, 
null; 

else 

—  Get  the  Reference  type 

Data.El ement. Record. Ref erence.Type;=  A.Fact (41. .65); 

—  Do  0(1)  procedure  call  to  update  the  data  element  in  the 

—  data  element  manager. 

Data.Element.Manager.Set_Data.Element_Reference.Type 

(Data.Element.Pointer ,  Data.Element.Record. Ref erence_Type) ; 
end  if; 
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—  get  Data  Element  Version  Facts  ♦♦♦ 


il  Environment _Types.Fact_Bulfer_Package.Is_Done(Fact_Pointer)  then 
Text^IO . Put^Line ( A^Fact ) ; 

Text_IO.Put_Line("I  am  Exception:  data-  '*); 
raise  Invalid„Fact_Sequence_For_Data_Element ; 
end  il; 

—  Advance  pointer  to  next  fact  in  manager.  0(1). 

Environment .Types. Fact _Buffer_Package.Get_Next(Fact_Pointer) ; 

—  Get  a  fact.  0(1)  time. 

A.Fact : =  Environment .Types . Fact.Buf f er.Package . Value.Of .Item 
(Fact .Pointer) ; 

—  This  fact  should  be  the  Data  Element  Version. 

if  A.Factd.  .12)  /=  "data-ele-ver**  then 
Text.IO.Put.Line(A.Fact) ; 

Text.IO.Put.LineC*!  am  Exp:  data-ele-ver  "); 
raise  Invalid.Fact.Sequence.For.Data.Element ; 
end  if; 

—  Columns  14  through  38  must  be  the  same  Data  element  name, 
if  A.Fact(14. .38)  /=  Data.Element_Record.Name  then 

Text. 10. Put. Line (A.Fact) ; 

Text.IO.Put.Line("I  am  Exp:  data-ele-ver .Name  "); 

raise  Invalid.Fact.Sequence.For.Data.Element ; 
end  if; 

—  Columns  40  through  49  hold  the  data  element  version  if  it  is 

—  not  null. 

if  A.Fact (40. .43)  =  "null"  then 

—  Do  nothing,  there  was  no  data  element  version, 
null; 
else 

—  Get  the  version. 

Data.Element.Record. version: =  A.Fact(40. .49); 

—  Do  0(1)  procedure  call  to  update  the  data  element  in  the 
—  data  element  manager. 

Data.Element.Manager. Set. Data.Element. Vers ion 

(Data. Element. Pointer ,  Data.Element. Record. Version) ; 
end  if ; 


—  get  Data  Element  Version  Changes  Facts 
—  Advance  pointer  to  next  fact  in  manager. 
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Environment.Types .Fact _Bufler_Package .Get _Next (Fact _Po inter) ; 

—  If  the  fact  buffer  is  empty  at  this  point  there  is  an  error 

—  in  the  format. 


if  Environment ^Types  .Fact_Buffer_Package  .Is_Done(Fact»Pointer)  then 
Text_IO.Put_Line(A_Fact) ; 

Text_IO.Put_Line(*'I  am  Exp:  data~e-v--chg.Is^Done  '*); 
raise  Invalid_Fact_Sequence_For_Data_Element ; 
end  if; 

—  Get  a  fact. 

A^Fact : =  Environment .Types . Fact.Buf f er.Package . Value.Of .Item 
(Fact.Pointer) ; 


—  The  series  of  fact(s)  should  be  the  Data  Element  Version  Changes. 

—  There  is  at  least  one  data-e-v-chg  fact  and  possible  more, 
if  A.Factd . .  12)  /=  ’*data-e~v-chg”  then 

Text_IO.Put.Line(A_Fact) ; 

Text.IO.Put.LineC’I  am  Exp:  data-e-v-chg.  '*); 
raise  Invalid.Fact.Sequence.For.Data.Element ; 
end  if; 

—  Columns  14  through  38  must  be  the  same  data  element  version  name, 
if  A.Fact(14. .38)  /=  Data.Eleraent.Record.Name  then 

Text.IO.Put.Line(A.Fact) ; 

Text.IO.Put.Line("I  am  Exp:  data-e-v-chg.Neane  “); 
raise  Invalid.Fact.Sequence.For.Data.Element ; 
end  if; 

—  If  the  version  change  is  null  then  we  are  done  with  this  attribute. 

—  Need  only  to  advance  the  pointer  by  one  for  the  outer  loop. 

if  A_Fact(40.  .43)  =  ‘’null”  then 

—  There  is  no  version  change  for  the  data  element,  so  just  advance 

—  the  fact  pointer. 

—  Advance  pointer  to  next  fact  in  manager.  0(1)  time. 

Environment .Types .Fact.Buffer.Package.Get.Nfxt (Fact. Pointer) ; 

else 

—  There  must  be  one  or  more  lines  in  the  version  changes, 

—  This  loop  will  run  x  times  where  x  is  the  number  of  times  in  the 

—  version  change. 


while  A.Fact(l . . 12)  =  ”data-e-v~chg”  loop 

—  I  realize  this  check  is  repetitive  on  the  first  iteration. 
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—  Columns  14  through  38  must  be  the  same  data  element  name. 

—  0(1)  time  complexity. 

if  A_Fact(14. ,38)  /=  Dat a.Element ^Record . Name  then 
Text.IO.  Put  .Line  (A^Fact)  ,* 

Text.IO.Put.Line(’*I  am  Exp:  data-e-v-chg .  while  "); 
raise  Invalid.Fact.Sequence.For.Data.Element ; 
end  if; 

—  Pull  the  version  from  the  fact. 

Version.Line:=  A.Fact(40. .99) ; 

—  Add  the  version  change  to  the  Version  Changes  part  of  the 

—  Data  Element  record.  0(1)  time. 

Environment . Types  .Text.Buffer.Package .  Add.Item 

(Version.Line,  Data.Element.Record.Version.Changes ,  The.Iterator) ; 

—  Advance  pointer  to  next  fact  in  raainager. 

Environment . Types .Fact.Buffer.Package . Get.Next (Fact.Pointer) ; 

—  If  it  is  not  empty  get  the  next  fact.  0(1)  time, 
if  not  Environment .Types .Fact. Buffer. Package . Is.Done 

(Fact.Pointer)  then 

A.Fact : =  Environment .Types .Fact.Buff er.Package .Value.Of. Item 
(Fact.Pointer) ; 

else 

—  If  this  is  the  last  fact  of  the  last  data  element  exit  the 
—  loop. 

Text.IO . Put_Line( A.Fact ) ; 

Text.IO.Put.Line(''I  am  Exp:  data-e-v-chg.  else  ”); 
raise  Invalid.Fact.Sequence.For.Data.Element ; 
end  if; 
end  loop; 


—  There  were  ^ne  or  more  lines  in  the  version  change  so  now  must 

—  place  them  with  the  data  element  in  the  data  element  manager.  0(1). 
Data.Element.Manager . Set.Data.Element.Version.Comments 

(Data.Element.Pointer ,  Data.Element.Record. Version.Changes) ; 

end  if; 


— get  Data  Element  Date  Facts  ***  - 

if  Environment. Types .Fact.Buff er.Package . Is.Done(Fact. Pointer)  then 
Text.IO . Put.Line(A.Fact) ; 

Text.IO  .Put .Line(*'I  aon  Exception:  data-  "); 
raise  Invalid.Fact.Sequence.For .Data.Element ; 


end  if; 
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—  Get  a  fact.  0(1)  time. 

A^Fact : =  Environment _Types . Fact^Buf f er.Package . Value_0f .Item 
(Fact.Pointer) ; 

—  This  fact  should  be  the  data  element  date. 

if  A.Factd  1 .13)  /=  ”data-ele~date’‘  then 
Text.IO . Put .Line (A.Fact ) ; 

Text.IO.Put_Line("I  am  Exp:  data-ele-data  "); 
raise  Invalid.Fact.Sequence.For.Data.Element ; 
end  if ; 

—  Columns  15  through  39  must  be  the  same  Data  element  name, 
if  A.Factdi.  .39)  /=  Data.Element.Record.Name  then 

TextllO. Put. Line (A.Fact) ; 

Text.IO.Put.LineC’I  am  Exp:  data-ele-data.Name  ’*); 
raise  Invalid.Fact.Sequence.For.Data.Element ; 
end  if; 

—  Columns  41  through  48  hold  the  data  element  date  if  it  is 

—  not  null. 

if  A.Fact(41..44)  =  "null"  then 

—  Do  nothing,  there  was  no  data  element  date, 
null ; 
else 

—  Get  the  date. 

Data_Element.Record.Date:=  A.Fact(41 . .48) ; 

—  Do  0(1)  procedure  call  to  update  the  Data  element  in  the 
—  Data  Element  manager. 

Data.Element .Manager . Set.Data.Element.Date 

(Data.Element. Pointer ,  Data.Element_Record.Date) ; 
end  if; 

—  Get  Data  Element  Author  Facts  *** - 

if  Environment .Types .Fact .Buff er.Package .Is.Done(Fact.Pointer)  then 
Text_IO.Put.Line(A_Fact) ; 

Text_IO.Put.Line("I  am  Exception:  data-element-author  Is.Done  **); 
raise  Invalid.Fact.Sequence.For .Data.Element ; 
end  if; 

—  Advance  pointer  to  next  fact  in  manager.  0(1). 

Environment.Types .Fact. Buff er.Package. Get. Next (Fact. Pointer) ; 

—  Get  a  fact.  0(1)  time. 

A.Fact : =  Env ironment .Types . Fact.Buff er.Package . Value.Of .Item 
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““  MODULE  NUMBER:  TBD 

“  DESCRIPTION: 

When  the  flag  Type_Of_Facts_Flag  is  set  to  true, it  means  the  — 
client  procedure  wants  all  the  facts  that  are  necessary  for  — 
the  .esm  file.  If  the  flag  is  false,  then  the  facts  for 
the  expert  system  are  returned.  Facts  of  the  same  type  have  — 
the  same  format  no  matter  where  they  are  destined.  In  this  — 
case,  the  historical  name  is  but  a  single  fact.  Future 
modifications  to  SAtool  II  could  include  more  information  in  — 
the  Historical_Activity_Manager  however,  thus  this  procedure  — 
is  of  use. 

—  historical  tuple  facts:  (retrieved  when  creating  a  ,esm  file  or 

when  performing  check  syntax) 

1)  a  predefined  attribute  name  (historical-name) 

2)  the  historical  name  (if  the  name  is  null,  the  word  *null^  is  — 
placed  in  the  field. 

—  ALGORITHM:  All  simple  0(1)  statements  and  2  0(1)  procedure  calls.  — 

—  PASSED  VARIABLES:  Type_Facts_Flag,  Fact .Manager 

—  RETURNS:  None 

—  GLOBAL  VARIABLES  USED:  None 

—  GLOBAL  VARIABLES  CHANGED:  None 

—  FILES  READ:  None 

—  FILES  WRITTEN:  None 

“  HARDWARE  INPUT:  None 

“  HARDWARE  OUTPUT:  None 

—  MODULES  CALLED:  None 

“  CALLING  MODULES:  TBD 

“  ORDER-OF:  0(1) 

—  AUTHOR(S) :  Min-fuh  Shyong 

—  HISTORY:  None  (Initial  Implementation) 


procedure  Retrieve.Historical.Activity .Facts 
(Type.Facts.Flag  :  in  boolean; 

Fact  .Manager  :,  in  out 

Environment .Types . Fact.Buf f er.Package . Mainager.Type )  is 


—  Local  Declaration  — 


Fact.Pointer 

A.Fact 

Blank.Fact 


:  Environment .Types . Fact.Buf f er.Package . Iterator .Type ; 

:  Environment .Types . Fact.Str ing.Type ; 

:  Environment .Types. Fact.Str ing.Type  :=  (others  =>  *  0; 


—  Historical  Activity  Declarations  — 

Historical. Activity. Record  : 

Historical.Activity.Class . Historical.Activity.Record.Type ; 
Historical.Activity.Pointer : 

Historical.Activity.Manager. Historical. Activity.Pointer.Type; 
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begin 


—  Clear  the  passed  in  lact^manager  — 

Environment  ^Types .  Fact^Buller^Package .  Cleair  (Fact^Manager) ; 

—  Reset  — 

Historical.Activity^Manager . Reset_Historical_Activity_Iterator ; 


—  take  facts  — 


while  not  Historical„Activity_Manager .Historical_Activity_Iterator^Done  loop 
Historical_Activity_Record  := 

Historical^Act ivity ^Manager. Value_Of_Historical_Activity_At_Iterator; 


A^Fact 

A_Fact(l. .16) 
A^Fact(17) 
A„Fact(l8. .42) 
A^Fact(43) 
A„Fact(44..63) 


Blank^Fact ; 

"historical -tuple" ; 

)  > . 

> 

Historical_Activity_Record . Pro j  ect ; 

}  > . 
t 

Historical_Activity_Record . Activity^Number ; 


—  Store  the  facts  — 

Environinent_Types .Fact^Buf f er^Package . Add_Item 
(A.Fact,  Fact^Manager,  Fact^Pointer) ; 

Historical_Activity_Manager . Advance_Iterator_To_Next_Historical_Activity ; 

end  loop; 

end  Retrieve_Historical_Activity_Facts ; 


—  DATE:  12/06/90 
~  VERSION:  1.0 

—  NAME:  ★♦♦PROCEDURE  RESTORE  HISTORICAL  AVTIVITY  FACTS^^^ 

—  MODULE  NUMBER:  TBD 

—  DESCRIPTION:  Restores  the  Historical  Activity  facts  into  the 

—  Historical  Activity  Manager 

—  ALGORITHM:  A  single  while  loop  controls  the  execution  with  an 

—  embedded  call  to  an  0(i)  procedure. 

—  PASSED  VARIABLES:  The_Fact_Buff er  (contains  the  Historical 

Activity  facts) 
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—  RETURNS:  None 

—  GLOBAL  VARIABLES  USED:  None 

—  GLOBAL  VARIABLES  CHANGED:  None 
--  FILES  READ:  None 

”  FILES  WRITTEN:  None 

—  HARDWARE  INPUT:  None 
“  HARDWARE  OUTPUT:  None 

—  MODULES  CALLED:  None 
--  CALLING  MODULES:  TBD 

—  ORDER--OF:  0(i  *  i)  where  i  is  the  number  of  facts  in  the  fact 

—  buffer  which  should  be  the  same  as  the  no.  of  Historical  Activity  — 

—  facts. 

—  Note  that  all  string  slice  operations  are  modeled  as  0(1)  time. 

“  AUTHOR(S) :  Min-fuh  Shyong 

—  HISTORY:  None  (Initial  Implementation) 


procedure  Restore_Historical_Activity_Facts 
(The^Fact^Buff er:  in 

Environment^Types . Fact^Buf f er_Package . Manager.Type )  is 


—  Local  Declaration  — 


Fact^Pointer 

A_Fact 

First^Char 

Char^Position 

Temp^Pos 


Environment^Types . Fact.Buf f er.Package . Iterator^Type ; 

Environment ^Types . Fact_String_Type ; 

natural  :=  0; 

natural  :=  0; 

natural  : =  0 ; 


—  Historical  Activity  Declarations  — 
Historical_Activity_Record  : 

Historical_Activity_Class . Historical_Activity_Record_Type ; 
Historical_Activity_Pointer : 

Ristorical_Activity„Manager . Historical_Activity_Pointer_Type ; 

—  add  new  variable  — 

Null_Historical_Activity_Record  : 

Historical_Activity_Class . Historical_Activity_Record_Type ; 


begin 

—  check  for  empty  buffer  of  facts.  If  empty,  do  nothing.  — 


if  Environment _Types.Fact_Buffer.Package.Is_Empty(The_Fact_Buffer)  then 
return ; 
end  if; 
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—  Initialize  iterator  to  first  historical  activity  facts  — 


Environment.Types . Fact_Buf f er^Package . Initial ize^Iterator 
(Fact.Pointer ,  The^Fact^Buff er) ; 

—  Engage  lop  to  extract  the  facts  froma  a  buffer  — 

—  This  loop  is  0(i)  time. 

—  Where  i  is  the  number  of  facts  in  the  buffer 

while  not  Environment _Types,Fact_Buffer_Package.Is„Done(Fact„Pointer)  loop 
—  Get  a  record 

A^Fact  :=  Environment _Types.Fact_Buffer_Package.Value_Of_Item 
(Fact_Pointer)  ; 

—  Since  we  put  the  information  in  the  string,  we  know  the 

—  exact  columns  where  information  should  be. 

—  All  String  assignments  are  modeled  as  0(1); 

—  Insure  the  fields  are  all  blanks 

Historical„Activity„Record  :=  Null_Historical_Activity_Record; 

—  Retrieve  the  facts 

Historical_Activity_Record. Project  :=  A_Fact(18. .42) ; 
Historical_Activity_Record. Activity_Nuraber  :=  A_Fact(44. .63) ; 

—  load  this  fact  back  into  Historical  Activity  Manager 

Historical^Act ivity_Manager . Create_Historical_Activity 

(Historical_Activity_Record,  Historical.Activity.Pointer) ; 

—  Advance  pointer  — 

Environment^Types . Fact^Buff er_Package . Get^Next (Fact^Pointer ) ; 
end  loop; 

end  Restore_Kistorical_Activity_Facts ; 


—  DATE:  12/01/90 

—  VERSION:  1.0 

—  NAME:  ♦♦♦  RETRIEVE  CALLS  RELATION  FACTS 

—  MODULE  NUMBER:  TBD 

—  DESCRIPTION: 

When  the  flag  Type_Of_Facts_Flag  is  set  to  true, it  means  the  — 
client  procedure  wants  all  the  facts  that  are  necessary  for  — 
the  .esm  file.  If  the  flag  is  false,  then  the  facts  for 
the  expert  system  are  returned.  Facts  of  the  same  type  have  — 
the  same  format  no  matter  where  they  are  destined.  In  this  — 
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case,  the  calls  name  is  but  a  single  fact. 

—  calls  relation  tuple  facts:  (calls-relation-tuple  Activity 

History-tuple) 

where  history  is  another  tuple  in  Historical  ^Activity 

—  ALGORITHM:  All  simple  0(1)  statements  and  2  0(1)  procedure  calls.  — 

—  PASSED  VARIABLES:  Type_Facts_Flag,  Fact.Manager 

—  RETURNS:  None 

—  GLOBAL  VARIABLES  USED:  None 

—  GLOBAL  VARIABLES  CHANGED:  None 
““  FILES  READ  :  None 

“  FILES  WRITTEN:  None 

—  HARDWARE  INPUT:  None 

—  HARDWARE  OUTPUT:  None 

—  MODULES  CALLED  :  None 

—  CALLING  MODULES:  TBD 

—  ORDER-OF:  0(1) 

—  AUTHOR(S):  Min-fuh  Shyong 

—  HISTORY:  None  (Initial  Implementation) 


procedure  Retrieve_Calls_Relation_Facts 
(Type„Facts_Flag  :  in  boolean; 

Fact^Manager  :  in  out 

Environment_Types .Fact^Buff er_Package.Manager_Type)  is 

—  local  declaration  — 

Fact^Pointer  :  Environment^Types .Fact.Buf f er_Package . Iterator_Type ; 

A.Fact  :  Environment„Types .Fact_String_Type ; 

Blank^Fact  :  Environment_Types .Fact_String_Type  :=  (others  =>  '  '); 

—  calls  related  declarations  — 

Calls_Relation_Record  :  Calls_Relation_Class .Calls.Relation.Record.Type; 
Calls„Relation_Pointer  :  Calls_Relation„Manager . Calls_Relat ion_Pointer_Type ; 

begin 

—  clear  the  buffer  — 

Environment^Types . Fact^Buf f er_Package . Clear (Fact.Manager) ; 

—  reset  — 

Calls_Relation_Manager . Reset_Call  j_Relation„Tuple_Iterator ; 

—  teke  facts  — 

while  not  Calls_Relation_Hanager .Calls_Relation_Tuple_Iterator_done  loop 
Calls^Relation_Record  := 
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Calls_Relation_Manager.Value_01_Calls_Relation_Tuple_At_Iterator; 


A_Fact 

A_Fact(1..20) 
A_Fact(21) 
A_Fact(22. .46) 
A_Fact(47) 
A_Fact(48. .72) 


A_Fact(73) 
A_Fact(74. .93) 


Blank_Fact ; 

"calls-relation-tuple" ; 

}  I  * 

f 

Calls_Relation_Record , Activity ; 

)  ) . 

I 

Calls^Relat ion^Record . History^Tuple . Pro j  ect ; 

—  with  one  more  »  extension  to  get  the 

—  nested  record  History _Tuple .Project 

t  >  * 
t 

Calls_Relat ion.Record . History.Tuple . Activity _Numb  ar ; 


Environment _Types .Fact _Buffer_Package .Add^Item 
(A^Fact,  Fact^Manager ,  Fact^Pointer) ; 


Calls_Relation_Manager. Advance_Iterator_To_Next_Calls_Relation_Tuple; 


end  loop; 


end  Retrieve_Calls_Relation_Facts ; 


—  DATE:  12/06/90 

—  VERSION:  1.0 

NAME:  ♦♦♦PROCEDURE  RESTORE  CALLS  RELATION  FACTS*^+ 

—  MODULE  NUMBER:  IBD 

—  DESCRIPTION:  This  procedure  accepts  a  buffer  of  calls  relation 

—  facts. 

—  Restores  that  information  into  the  calls  relation  manager. 

—  Of  special  note  is  that  the  procedure  assumes  the  facts  are  in  the  — 

—  same  order  in  which  they  were  stored. 

—  ALGORITHM:  A  single  while  loop  controls  the  execution  with  an 

—  embedded  call  to  an  0(i)  procedure. 

—  PASSED  VARIABLES:  The_Fact_Buf f er  (contains  the  facts) 

—  RETURNS:  None 

—  GLOBAL  VARIABLES  USED:  None 

—  GLOBAL  VARIABLES  CHANGED:  None 

—  FILES  READ:  None 

—  FILES  WRITTEN:  None 

—  HARDWARE  INPUT:  None 

—  HARDWARE  OUTPUT:  None 

—  MODULES  CALLED:  None 

—  CALLING  MODULES:  Essential_10 . Restore_Proj ect 

—  ORDER-OF:  order  of  is  0(a  ♦  max  (x.  a))  where  a  is  the 

—  number  of  calls,  x  is  the  number  of  lines  in  a  historical  activity  — 

—  Note  that  all  string  slice  operations  are  modeled  as  0(1)  time. 

—  AUTHOR(S) :  Min-fuh  ohyor.g 

—  HISTORY:  None  (Initial  Implementation) 
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procedure  Restore^Calls^Relation^Facts 
(The^Fact^Buffer  :  in 

Enviroiunent^Types. Fact 3uffer_Package. Manager _Type)  is 

—  Local  Declarations  — 

Fact_Pointer :  Environment .Types . Fact.Buf 1 er.Package . Iterator .Type ; 

A.Fact :  Environment .Types . Fact.Str ing.Type ; 

First. Char:  natural :=  0; 

Char.Position:  natural :=  0; 

Temp.Pos:  natural :=  0; 

More.Descriptions.Flag:  boolean; 

—  Calls  Relation  Related  Declarations  — 

Calls.Relat ion.Record :  Calls.Relation.Class . Calls.Relat ion.Record.Type ; 
Calls.Relation.Pointer:  Calls_Relation_Manager.Calls.Relat3on_Pointer.Type; 


Null.Calls.Relat ion.Record :  Calls.Relation.Class . Calls.Relat ion.Record.Type ; 

— The.It erator :  Environment .Types . Text.Buf f er.Package . It erat or.Type ; 

— A.Descr ipt ion.Line :  Environment .Types . DD.Text.Type ; 

— A.Child:  Environment.Types .DD.Field.Type; 

— Found.Flag:  booleam:=  False; 

— Result. Flag:  boolean; 

—  Exception  — 

—  This  exception  is  declared  here  because  the  Essential  10  package  does 

—  not  check  to  see  the  facts  are  in  any  specific  order. 

— Invalid.Fact.Sequence.For.Cals.Relation:  exception; 

— Act ivity.Hierarchy. Error .During.Restore:  exception; 

begin 

—  Check  for  empty  buffer  of  facts.  If  empty,  do  nothing. 

if  Environment.Types .Fact .Buff er.Package. Is. Empty (The.Fact. Buff er)  then 
return; 
end  if; 


—  Initialize  iterator  to  first  tuple  fact 

Environment.Types . Fact.Buff er.Package . Initialize. Iterator 
(Fact.Pointer ,  The.Fact.Buff er) ; 

—  Engage  loop  to  extract  the  cassl  relation  facts  from  a  buffer 
—  one  at  a  time 

while  not  Environment.Types .Fact.Buff er.Package. Is.Done(Fact_Pointer)  loop 
—  Get  a  record. 


A^Fact : =  Environment .Types .Fact.Buf f er.Package . Value.Of .Item 
(Fact.Pointer) ; 


Calls.Relation.Record  :=  Null.Calls.Relation.Record; 


Calls.Reldtion.Record. Activity  :=  A.Fact(22. .46) ; 
Calls.Relation.Record. History .Tuple. Project  :=  A.Fact(48. .72) ; 
Calls.Relat ion.Record. History .Tuple. Activity.Number  :=  A.Fact(74. .93) 


Calls.Relation.Manager. Great e.Calls.Relation.Tuple 

(Calls.Relation.Record,  Calls.Relation.Pointer) ; 

Environment .Types . Fact.Buf f er.Package . Get.Next (Fact.Pointer) ; 
end  loop; 

end  Restore.Calls.Relation.Facts ; 


--  DATE;  12/03/90 

—  VERSION:  1.0 

—  NAME:  RETRIEVE  CONSISTS  OF  RELATION  *** 

“  MODULE  NUMBER:  TBD 

—  DESCRIPTION: 

When  the  flag  Type.Of.Facts.Flag  is  set  to  true, it  means  the  — 
client  procedure  wants  all  the  facts  that  are  necessary  for  — 
the  .esm  file.  If  the  flag  is  false,  then  the  facts  for 
the  expert  system  are  returned.  Facts  of  the  samr,  type  have  — 
the  same  format  no  matter  where  they  are  destined.  In  this  — 
case,  the  historical  name  is  but  a  single  fact.  Future 
modifications  to  SAtool  II  could  include  more  information  in  — 
the  Historical.Activity.Manager  however,  thus  this  procedure  — 
is  of  use. 

—  consists  of  relation  facts:  (retrieved  when  creating  a  .esm  file  — 

—  or  when  performing  check  sysntax 

1)  a  predefined  attribute  name  (consists-of-name) 

2)  the  consists  of  name  (if  the  name  is  null,  the  word  ‘null*  is  — 
placed  in  the  field. 

—  ALGORITHM:  All  simple  0(1)  statements  eoid  2  0(1)  procedure  calls. 

—  PASSED  VARIABLES:  Type.Facts.Flag,  Fact.Manager 

—  RETURNS:  None 

—  GLOBAL  VARIABLES  USED:  None 

—  GLOBAL  VARIABLES  CHANGED:  None 

—  FILES  READ:  None 

—  FILES  WRITTEN*  None 

“  HARDWARE  INPUT:  None 

—  HARDWARE  OUTPUT:  None 

—  MODULES  CALLED:  None 

—  CALLING  MODULES:  TBD 

—  ORDER-OF:  0(1) 
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—  AUTHOR(S) :  Min-luh  Shyong 

—  HISTORY:  None  (Initial  Implementation) 


procedure  Retrieve_Consists_Of_Relation_Facts 
(Type.Facts^Flag  :  in  boolean; 

Fact.Manager  :  in  out 

Environment _Types .  Factjuf f  er^Package .  Manager.Type)  is 

—  local  declaration  — 

Fact^Pointer  :  Environment _Types .Fact 3uffer_Package. Iterator .Type; 

A.Fact  :  Environment .Types. Fact.String.Type; 

Blank.Fact  :  Environment . Types . Fact .String.Type  :=  (others  =>  *  ’); 

—  consists  oi  declarations  — 

Consists.Ol.Relation.Record  : 

Consists.Of .Relation.Class . Consists.Of _Relation_Record.Type ; 
Consists.Of.Relation.Pointer  : 

Consists.Of.Relation.Manager.Consists_Of_Relation.Pointer.Type; 

begin 

—  Clear  the  passed  in  fact.memager  — 

Environment .Types . Fact.Buff er.Package . Clear (Fact.Manager) ; 

—  Reset  — 

Consists.Of.Relation.Manager .Reset.Consists.Of.Relation.Tuple.Iterator; 


—  take  facts  — 

while  not  Consists.Of.Relation.Maoiager . 

Consists.Of.Relation.Tuple.Iterator.Done  loop 

Consists.Of.Relation.Record: = 

Consists.Of.Relation.Manager . 

Value.Of.Consists.Of.Relation.Tuple.At.Iterator; 

A.Fact  :=  Blank.Fact; 

A.Fact(l . . 16)  :=  "consists-of-name" ; 

A.Fact(17)  ^ 

A_Fact(18. .23)  := 

Padded.String(int€ger ’ image(Consists. Of. Relation.Record. Consists. Of .Id)  ,  6) ; 
A.Fact (24)  :=  * 

A.Fact (25. .49)  ;=  Consists.Of.Relation.Record. Parent ; 

A.Fact(50)  :=  *  *; 
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A_Fact(51. .75)  :=  Consists_Of_Relation.Record. Child; 


Environment .Types . Fact^Bufl er^Package . Add_Item 
(A.Fact,  Fact .Manager ,  Fact.Pointer) ; 

Consist s.Oi.Relation.Manager . 

Advance.Iterator.To.Next.Consists.Ol.Relation.Tuple; 

end  loop; 

end  Retrieve.Consists.Ol.Relation.Facts ; 


—  DATE:  12/06/90 

—  VERSION:  1,0 

—  NAME:  ***PROCEDURE  RESTORE  CONSISTS  OF  RELATION  FACTS***  — 

—  MODULE  NUMBER:  TBD 

—  DESCRIPTION:  Restores  the  consists  of  relation  facts  into  the 

—  Consists  Of  Relation  Manager 

—  ALGORITHM:  A  single  while  loop  controls  the  execution  with  an 

—  embedded  call  to  an  0(i)  procedure. 

—  PASSED  VARIABLES:  The.Fact. Buffer  (contains  the  consists  of 

—  relation  facts) 

—  RETURNS:  None 

“  GLOBAL  VARIABLES  USED:  None 

—  GLOBAL  VARIABLES  CHANGED:  Hone 

—  FILES  READ:  None 

—  FILES  WRITTEN:  None 

—  HARDWARE  INPUT:  None 

—  HARDWARE  OUTPUT:  None 
~  MODULES  CALLED:  None 

—  CALLING  MODULES:  TBD 

—  ORDER-OF:  0(i  *  i)  where  i  is  the  number  of  facts  in  the  fact 

—  buffer  which  should  be  the  same  as  the  no.  of  Consists  of  relation  — 

—  facts. 

—  Note  that  all  string  slice  operations  are  modeled  as  0(1)  time. 

—  AUTHOR(S):  Min-fuh  Shyong 

—  HISTORY:  None  (Initial  Implementation) 


procedure  Restore.Consists.Of.Relation.Facts 
(The.Fact.Buffer :  in 

Environment .Types . Fact.Buf f er.Package . Manager.Type)  is 


—  Local  Declaration  — 


Fact.Pointer 
A.Fact 
First. Char 


:  Environment .Types . Fact.Buf f er.Package . Iterator.Type ; 
:  Environment .Types . Fact.String.Type ; 

:  natural  :=  0; 
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Char^Position  :  natural  :=  0; 
Temp^Pos  :  natural  :=  0; 


—  Consists  Oi  Relation  Declarations  — 
Consists_01_Relation_Record  : 

Consists_01_Relation_Class . Consists_0f_Relation3ecord_Type ; 
Consists^Of .Relation^Pointer : 

Consist s_01_Relation_Manager . Consists_01 3elation_Pointer_Type ; 

—  add  new  variable  — 

Null^Consists^Oi.Relation^Record 

Consists_01_Relation_Class.Consists_01_Relation.Record_Type; 


begin 

—  check  ioT  empty  buffer  of  facts.  If  empty,  do  nothing.  — 


if  Environment^Types .Fact^Buff er_Package.Is_Empty(The_Fact_Buff er)  then 
return; 
end  if; 

—  Initialize  iterator  to  first  consists  of  relation  facts  — 

Environment .Types .Fact_Buffer_Package . Initialize.Iterator 
(Fact.Pointer,  The.Fact.Buff er) ; 

—  Engage  lop  to  extract  the  facts  froma  a  buffer  — 

—  This  loop  is  0(i)  time. 

—  Where  i  is  the  number  of  facts  in  the  buffer 

while  not  Environment .Types, Fact_Buffer.Package.Is.Done(Fact_Pointer)  loop 
—  Get  a  record 

A.Fact  :=  Environment .Types .Fact.Buffer.Package. Value.Of. Item 
(Fact.Pointer)  ; 

—  Since  we  put  the  information  in  the  string,  we  know  the 
—  exact  columns  where  information  should  be. 

—  All  String  assignments  are  modeled  as  0(1); 

—  Insure  the  fields  are  all  blanks 

Consists.Of .Relation.Record  : =  Null.Consists.Of .Relation.Record ; 

—  Retrieve  the  facts 

Consists. Of .Relation.Record . Consists.Of .Id  :  = 

integer  *  value ( A. Fact (18. .23)) ; 
Consists.Of .Relation.Record. Parent  :=  A.Fact(25. .49) ; 
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Consist s_Of_Relation_Record, Child  :=  A_Fact(51 . .75) ; 

—  load  this  fact  back  into  Consists  Of  Relation  Manager 

Consists_Of_Relation_Manager.Create_Consists_Of_Relation_Tuple 
(Consists„0f3elation_Record,  Consists^Of ^Relation^Pointer) ; 

—  Advance  pointer  — 

Environment _Types.Fact_Buffer_Package.Get_Next(Fact_Pointer) ; 
end  loop; 

end  Restore_Consists_Of _Relation_Facts ; 


end  Essential_Fact_Utilities; 
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Appendix  C.  CLIPS  RULE  BASE 


If  4c  4c  4c  %  4c  4c  4c  J||  >|t  4c  4c  4(  ^  4c  4: t  ^  4c  %  it  it  >|(  %  >|(  t  t  t 

;  Essential  Subsystem  Rule  Base  ; 

j  ^  —  j 

;  File  Name:  satool2.clp  ; 

;  Date  Last  Updated:  24  May  1991 

;  Author:  Min-fuh  Shyong,  GCS“91j  ; 

;  Points  of  Contact:  Dr.  Gary  Lamont  ; 

;  DESCRIPTION:  ; 

;  This  file  contains  the  rule  base  used  by  ; 

;  the  CLIPS/Ada  expert  system  portion  of  the  Essential  ; 

;  Subsystem.  The  idea  was  initiated  by  Terry  Kitchen  in  ; 

;  his  thesis  but  needs  to  be  expanded  and  completed  for  the  ; 

;  follow  on  researchers.  This  subsystem  is  to  eventually  be  ; 

;  integrated  with  another  system  to  form  SAtool  II,  which  ; 

;  with  another  system  to  form  SAtool  II,  which  is  an  Ada  ; 

;  is  an  Ada  based  IDEFO  development  tool.  ; 

;  PURPOSE: 

;  The  purpose  of  this  rule  base  is  to  check  the  ; 

;  syntactic  features  of  an  IDEFO  model  whose  representation  ; 
;  has  been  converted  to  CLIPS  readable  facts.  ; 

;  METHODOLOGY: 

;  Whenever  the  "check  syntax"  option  is  chosen  within  ; 

;  the  Essential  Subsystem  main  menu,  this  rule  base  is  loaded; 

;  into  the  working  memory  of  the  CLIPS/Ada  expert  system.  ; 
;  The  same  option  also  begins  the  "recognize-act"  cycle  of  ; 
;  the  CLIPS  inference  engine  which  uses  the  rules  below  to  ; 
;  "match"  the  LHS  of  rules  with  facts,  resolve  conflicts  ; 
;  among  eligible  rules,  and  then  fire  the  RHS  of  rules,  until; 
;  no  rules  are  eligible  to  fire.  This  file  must  be  within  ; 
;  SCOPE:  ; 

;  At  the  present  time,  this  rule  base  checks  the  ; 

;  syntactical  features  associated  with  the  "essential"  data  ; 
;  of  an  IDEFO  model.  ; 

;  RULES  AND  THEIR  FUNCTION:  ; 

;  The  following  IDEFO  syntax  checking  rules  are  completed:  ; 

»  p 

;  1.  Each  activity  is  checked  to  ensure  it  has  at  least  one  ; 

;  output  and  one  control.  ; 

;  2.  For  each  activity,  the  number  of  its  input,  output,  ; 

;  control  and  mechanisms  is  checked  to  suggest  that  they  ; 

;  are  not  more  than  5.  ; 

;  3.  The  project  is  checked  to  ensure  a  name  is  given  for  ; 

;  the  project.  ; 

;  4.  Each  activity  is  checked  to  ensure  an  activity  number  ; 

;  is  assigned.  No  duplicated  activity  name  is  also  ; 

;  checked.  ; 

;  5.  Each  activity  is  checked  to  ensure  some  description  ; 


are  associated  with  that  activity.  ;; 

6.  Each  data  element  is  checked  to  make  sure  that  the  ;; 

data  name,  description  are  provided.  And  no  duplicated  ;; 
data  element  name  exists .  ; ; 

7.  Each  parent  activity  with  a  child  name  with  it,  the  ;; 

child *s  name  must  be  found.  ;; 

8. '  Hierarchical  rules  for  creating  boundary  arrow  facts  j; 

between  any  parent  with  2,  3,  4,  5,  or  6  child  ;; 

activities  are  implemented.'  ; ; 

9.  Rules  for  checking  the  consistency  between  those  parent  ;; 

diagram  and  their  child  diagrams  are  provided.:  ; ; 

10.  Rule  for  checking  inconsistent  icom  code  between  parent  ;; 

and  child  diagreons .  ; ; 

11.  Rule  to  check  if  any  parent  activity  has  more  than  6  ;; 

child  diagrams ..  ; ; 

12. :  Utility  rules  builds  up  the  syntax  checking  ;; 

environment.  ;; 

13.  Boundary  icom  number  consistency  checking  rules.  ;; 

14.  Auxiliary  rules  supporting  the  hierarchy  checking  rules.;; 

OUTPUT:  ;; 

IDEFO  syntax  violations  cause  the  user  to  receive  ; ; 

five  kinds  of  messages:  ;; 

1.  CONGRATULATORY:  No  syntax  errors  was  found.  If  no  ;; 

syntax  error  facts  was  asserted  after  the  ; ; 
rules  checking  is  done,  then  this  message  ;; 
will  be  presented  at  the  end  of  all  the  ; ; 
other  messages  ;; 

2.  ERRORS:  Syntax  error  encountered,  syntax  error  ;; 

fact  will  be  asserted,  program  will  be  ; ; 

halted  after  all  the  checkings  are  done.  ;; 

3.  WARNING:  Some  features  of  the  users  project  work  ;; 

were  discovered  that  might  cause  problem.  ;; 

4.  NOTICE:  Reminder  to  the  user  that  something  should  ;; 

be  carefully  done.  ;; 

5.  SUGGESTION:  Suggest  the  user  that  further  manually  ;; 

recheck  might  be  helpful  to  find  ; ; 

logical  errors  that  cannot  be  found  by  ; ; 
the  syntax  checking  rules.  ;; 


4c4c4c4c4c4c4c4c4c***4c4(4c4c4c4c****  Environment  Utility  rule 
These  rules  does  not  do  the  syntax  checking  functions,  but  are  necessary 
for  the  syntax  checking  package. 


This  x'Oe  prints  out  the  necessary  headings  for  the  syntax  checking 
functions,  ^t  is  guaranteed  by  the  salience  declaration  to  be  fired  first. 
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(delrule  print-intr eduction 
(declare  (salience  5000)) 

(initial-lact) 

=> 

(printout  t  crll  Essential  Subsystem  Syntax  Checking  Messages 

crlf) 

) 


;  Right  iollowing  the  heading,  the  name  oi  the  project  to  be  checked  is 
;  print  our  by  this  rule. 


(delrule  print -project-name 
(declare  (salience  4999)) 

(project-name  ?name) 

=> 

(printout  t  '*===>  The  project  ==  *’?name  ”  ==  is  checked  as  follows:*'  crlf  crlf) 

) 


;If  any  errors  have  occured,  this  rule  will  stop  the  system  at  this  point. 


999999999999999999999999999999>>9-999t99t99*99999999f99999t9999999999999999 


(defrule  exit-if-error 
(declare  (salience  -8)) 
(syntax-error-occurred) 
=> 

(halt) 

) 


9t9i9t99t999tttt999t9ti9fttt9>t9ft9f99»t9>$9ttt*i999999t9f99tft9999t9t999999 

;  If  no  errors  were  found,  then  a  congratulatory  message  will  be  presented, 

;  but  also  reminds  the  usei  to  check  his  work  again. 

9tt999t99lt9999999*9$99*9t9tt9tttt999ttt99999»tt9tt9t9i9it999tf9ttt9%999999t 


(defrule  no-error-congratulate 
(declare  (salience  -8)) 

(not  (syntax-error-occurred)) 

=> 

(printout  t  "CONGRATULATIONS:  No  syntax  errors  encountered."  crlf) 

(printout  t  "  SUGGESTION:  Please  recheck  logical  structure  of  your  project  "  crlf) 
(printout  t  "  for  perfection"  crlf  ) 

) 


•  rules  for  icora-facts  ******^**********t********* 

;  Those  rules  check  possible  errors  that  could  happen  in  icom  facts 


999999»9999ff9999i9*999999f9>9f99999f999999t9t999  f,  >99f99f99t999f»99t99*99f999^ 


C.:-3 


;  If  an  activity  has  no  output,  no  control,  than  it  is  an  syntax  error. 


(defrule  zero-outputs 

(icom-activity-outputs  ?act  0) 

=> 

(printout  t  "ERROR:  Activity  "  ?act  "  needs  at  least  1  output.'* 
crlf  ) 

(assert  (syntax-error-occurred)) 

) 


(defrule  zero-controls 

(icora-activity-controls  ?act  0) 

=> 

(printout  t  "ERROR:  Activity  "  ?act  "  needs  at  least  1  control." 
crlf  ) 

(assert  (syntax-error-occurred)) 

) 


9999999999>99999>9*99999999999999>999999999999>99>9999>99999>99999999>>9*9t 

Checks  if  the  inputs,  mechanisms,  controls  or  outputs  of  an  activity 
is  more  that  5,  than  a  warning  message  will  be  presented. 


(defrule  too-many-mechs 

(icom-activity-mechanisms  ?act-mech  ?num-raech) 

(test  (>  ?num-mech  5)) 

=> 

(printout  t  "WARNING:  Activity  "  ?act-mech  "  has  too  many 
mechanisms."  crlf) 

) 


(defrule  too-many-outputs 

(icom-activity-outputs  ?act-out  ?num-out) 

(act-numb  ?act-out  ?out-num) 

(test  (>  ?num-out  5)) 

=> 

(printout  t  "WARNING:  Activity  "  ?out-num  "  "  ?act-out  "  has  too  many 
outputs."  crlf) 


(defrule  too-many-controls 

(icom-activity-controls  '^act-cont  ?num-cont) 
(act-numb  ?act-cont  ?cont-num) 
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(test  (>  ?num-cont  5)) 

(printout  t  "WARNING:  Activity  "  ?cont-nuin  "  "  Tact-cont  "  has  too  many 
controls."  crll) 


(delrule  too-many-inputs 
(icom-activity-inputs  ?act“in  ?nuro-in) 

(test  (>  ?num^in  6)) 

=> 

(printout  t  "WARNING:  Activity  "  ?act-in  "  has  too  many  inputs."  crll) 

) 

j  ruleS  fOr  prO j ect"! aCtS 

;  The  only  rule  for  a  project  is  to  check  if  there  is  a  project  name. 


(defrule  null-pro j  ect-naiae 
(declare  (salience  8)) 
(project-name  null) 


(printout  t  "ERROR:  The  current  project  does  not  have  a  name, 
crlf) 

(assert  (syntax-error-occurred)) 

) 


i(^4,t^ii^*i:4‘********t******i^*  rules  for  activity-facts 

Those  rules  check  if  the  necessary  attributes  of  an  activity  is  missing 


;  Any  activity  should  have  an  activity  number  assigned  to  it. 


9999999999999999999999999999999999999999999999999999999999999999999999999 


(defrule  null-activity-number 
(act-numb  ?activity  null) 

=> 

(printout  t  "ERROR:  Activity  "  ?activity  "  must  be  numbered." 
crlf) 

(assert  (syntax-error-occurred))  ) 


999999999999999999999999999999999999999999999999999999999999 

;  Each  avtivity  should  have  a  description,  if  not, 

;  this  rule  will  raise  a  warning. 

9999999999999999999999999999999999999999999999999999999999999 
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(delrule  null-activity-description 
(act--desc  ?activity  null) 

(act-numb  ?activity  ?num) 

=> 

(printout  t  **VARNING:  Activity  number  **  ?num  **  **  ?activity  ''  needs  a 
description.”  crll)) 


II  any  activity  has  a  activity  number  with  the  last  digit  more  than 
6,  than  that  means  its  parent  has  more  than  6  child  activities. 

999999999999999999999999999999*99999999999999999999999999999999999999 


(defrule  too-many~children~levell 
(act  ?act  ?end-num) 

(test  (>  ?end-*num  6)) 

=> 

(printout  t  “Waring:  activity  AO  has  more  than  6  child  diagraons.”  crlf) 

(printout  t  “Notice:  Please  manually  check  to  make  sure  that  there  is  no“  crlf) 
(printout  t  “  such  an  warning  lower  that  4  levels  of  hierarchy.”  crlf) 

) 

(defrule  too“many-children-level2 
(act  ?act  ?num  Tend-num) 

(test  (>  ?end-num  6)) 

=> 

(printout  t  “Wairing:  activity  A“?num  “  has  more  thaoi  6  child  diagraans."  crlf) 
(printout  t  “Notice:,  Please  manually  check  to  make  sure  that  there  is  no”  crlf) 

(printout  t  “  such  an  warning  lower  that  4  levels  of  hierarchy.”  crlf) 

) 

(defrule  too-many~children-level3 
(act  ?act  ?nl  ?n2  Tend-num) 

(test  (>  ?end-num  6)) 

=> 

(printout  t  “Waring;  activity  A”?nl  ?n2  "  has  more  thain  6  child  diagrams.”  crlf) 
(printout  t  “Notice:  Please  manually  check  to  make  sure  that  there  is  no”  crlf) 

(printout  t  ”  such  an  warning  lower  that  4  levels  of  hierarchy.”  crlf) 

) 


rules  for  hierarchical  boundary  consistency  checks  ♦♦♦♦♦♦ 


The  boundary  data  element  name  and  icom  code  of  a  parent  activity 
must  be  consistent  with  its  child  diagrams.  Those  rules  create  a 
set  of  boundary  facts  to  be  checked  for  their  consistency. 

The  assumption  made  here  is  that  any  parent  activity  should  not  have 
more  them  six  child  diagrams.  So  the  rules  are  implemented 
to  create  boundary  facts  for  parent  activity  with  2,  3,  4,  5,  and  6 
child  diagrams  separately. 

Another  set  of  rules  will  be  used  to  check  the  created  boundary  facts 
for  activities  with  different  or  same  number  of  child  activities. 
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;  These  rules  create  boundary  facts  for  a  parent  activity  with 
;  two  child  diagrams.  The  first  level  rule  creates  those  initial 
;  boundary  facts,  the  second  level  rules  clear  the  data  in  child 
;  diagrams  that  are  not  boundary  ;  data  in  contrast  with  their 
;  brother  diagrams. 


(defrule  parent-2child 
(declare  (salience  100)) 

?f l<~(act-has-child  ?parent2  Tchildlft^null) 
?f2<-(act“has-child  ?parent2  ?child2&"?childl&''null) 
(not  (act-has-child  ?parent2 

?child3&'*?child2&''?childl&''null)  ) 

=> 

(retract  ?fl  ?f2) 

(assert  (parent2  ?parent2  ?childl  ?child2)) 

) 


(defrule  parent2“boundary 

(parent2  ?parent2  ?childl  ?child2) 

(icom-tuple  ?parent2  Tp-data  ?p--rel  ?) 

=> 

(assert  (parent2“boundary  ?parent2  ?p  Jata  ?p-rel)) 

) 

(defrule  child2-boundary-childl 
(parent2  ?parent2  ?childl  ?child2) 

(icom-tuple  ?childl  ?cl-data  Tcl-rel  ?) 

=> 

(assert  (child2-boundary  ?parent2  ?childl  ?cl-'data  ?cl-rel)) 

) 

(delr.ule  child2-boundary-child2 
(parent2  ?parent2  ?childl  ?child2) 

(icom-tuple  ?child2  ?c2-data  ?c2-rel  ?) 

=> 

(assert  (child2“boundary  ?parent2  ?child2  ?c2-data  ?c2“rel)) 

) 


The  (child2-boundary  . )  facts  created  by  the  previous  rule 

are  only  initial  boundary  facts,  which  means  they  still 

have  all  the  data  element  in  the  facts.  But  the  data  shared  by  any  two 

different  child  activities  with  different  icom  code  will  not  be  boundary 


arrows  for  the  child  activities. 

They  should  be  retracted  from  the 

facts  already  created  before  the  boundary  checking  actually  performs. 
And  they  must  be  executed  after  all  the  initial  boundary  facts  are 
already  created.  This  is  guaranteed  by  a  higher  salience  declaration  in 
the  previous  rule. 


(defrule  clear-2child-roid 

?f l<-(child2“boundary  ?parent2  ?childi  ?cl-data  ?cl-rel) 
?f2<-(child2-boundary  ?parent2  ?child2&''?childl  ?cl-data  ?c2-relA'*?cl~rel) 
=> 

(retract  ?fl) 

(retract  ?f2) 

) 


;  This  rule  erase  one  of  the  duplicated  boundary  arrow 
;  for  the  icom  number  check. 


(defrule  remove-2child“2boundary 

?fl<-  (child2“boundary  ?parent2  ?childl  ?cl-data  ?cl-rel) 

(child2-boundary  ?parent2  ?child2&'’?childl  ?cl-data  ?cl-rel) 

=> 

(retract  ?fl) 

) 


;  If  201  intermediate  data  consists  subcomponents,  it  should  be 
;  retracted  as  well. 


(defrule  rid-2child-2consists 

?f l<’-(child2“boundary  ?parent2  ?childl  ?cl-data  ?cl-rel) 

?f2<“(child2“boundary  ?parent2  ?childl  ?c2-data&‘'?cl-data  ?c2“rel&'’?cl"rel) 
?f3<“(child2~boundary  ?parent2  Tchild-pfe" ? child 1  ?cp“data&‘'?cl-data&~?c2-data 

?cp-rel&"?cl“rel&"?c2“rel) 

( cons ists-of -name  ?  ?cp-data  ?c2-data) 

(consists-of-name  ?  ?cp-data  ?cl-data) 


=> 

(retract  ?fl  ?f2  ?f3) 

) 


»  »  »  »  t  »  t  »  >  *  I  »  »  f  f  r  f  I  f  f  »  f  >  I  I  »  f  »  »  »  f  I  I  »  »  )  »  »  »  f  I  »  t  »  »  f  t  >  »  I  f  I  »  »  >  >  I  >  I  >  f  »  }  *  >  )  f  >  f 

;  For  those  parent  activity  with  two  child  diagrams, 

;  if  a  parent  boundary  data  can't  be  found  in  the  child  boundary  data 
;  or  the  parent  data  is  not  a  parent-data  of  the  child  data, 

;  than  parent  inconsistency  occurred. 
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(delrule  check~2child-parent 
(declare  (salience  -5)) 

(parent 2-boundary  ?p-narae  ?p-data  ?p-rel) 

(not  ( consist s-ol-name  ?  ?p-data  ?c-data)) 

(not  (child2-boiindary  ?p-naiae  ?childlor2  ?p-data  ?c-rel)) 

=> 

(printout  t  “ERROR:  Data  inconsistency  between  parent  activity"  crll) 
(printout  t  “  '*  ?p-nasic  “  data  ?p-rel  '**  “  ?p-data  “  and  its'*  crlf) 

(printout  t  “  child  diagrams*'*  crlf) 

(assert  (syntax-error-occurred)) 


(defrule  check-2child-parent-consists 
(declare  (salience  -6)) 

(parent2-boundary  ?p-naine  ?p-data  ?p-rel) 

(consists-of-name  ?  ?p-data  ?c-data) 

(not  (child2-boundary  ?p-nanie  ?child2  ?c-data  ?c2-rel)) 

=> 

(printout  t  “ERROR:  Data  inconsistency  between  parent  activity 
''?p-name  “  data  ?p-rel  “  ?p-data  “  and  its  child 
diagrams."  crlf) 

(assert  (syntax-error-occurred)) 

) 


If  a  parent  finds  a  child  with  same  data  but  different 
relation,  then  it  is  an  icom  inconsistency. 


(defrule  check-2child-parent-icom 
(declare  (salience  -5)) 

(parent2-boundary  ?p-name  ?p-data  ?p-rel) 

(child2-boundary  ?p-name  ?childl  ?p-data  ?c-rel) 

(test  (neq  ?p-rel  “^c-rel)) 

=> 

(printout  t  “ERROR:  icom  inconsistency  between  activity  “  crlf) 
(printout  t  “  “  ?p-name  '*  and  its  child  diagram  '*  ?childl  crlf) 

(assert  (syntax-error-occurred)) 


;  This  rule  checks  if  a  data  in  child  is  not  in  their  parent 
;  than  child  inconsistency  with  its  parent  occurred. 
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(delrule  check-2child-child 
(declare  (salience  -5)) 

(child2-botindary  ?p-narae  ?childl  ?cl-data  ?cl-rel) 
(not  (consists-ol-name  ?  ?p-data  ?c-data)) 

(not  (parent2“boundary  ?p-najne  ?cl~data  Tp-rel)) 

=> 

(printout  t  "ERROR:  Data  inconsistency  between  child 
activity  "  ?childl  "  data  Tcl-rel  "  ?cl-data 
"  and  its  parent."  crl^) 

(assert  (syntax-error-occurred) ) 

) 


Boundary  icom  number  rules 


Those  hierarchical  rules  will  create  a  set  of  facts  calculating 
and  accumulating  the  control,  output,  input,  and  mechanisms  numbers 
for  each  parent  activity  and  their  child  activities  boundary  icom  facts. 

Note  that  these  rules  are  dependants  of  those  used  to  create  boundary 
facts  for  each  pair  of  parent  and  child  activities.  So  their  salience  must 
be  lower  to  be  fired  later  after  those  boundary  facts  have  already 
been  created. 


Parent  with  2  child  diagrams 


;  The  initial  icom  number  will  be  build  up  by  these  rules; 

(defrule  p2urent2-icom-c 
(declare  (salience  -2)) 

(parent2-boundary  ?p2“n2une  ?cl  ?c2  ?p2-data  c) 

=> 

(assert  (parent2-icom  ?p2-name  ?p2-data  control  1)) 

) 

(defrule  parent2-icom-o 
(declare  (salience  -2)) 

(parent2-boundary  ?p2-name  ?cl  ?c2  ?p2-data  o) 

=> 

(assert  (peu:ent2-icom  ?p2-name  ?p2-data  output  l)) 

) 


(defrule  parent2-icom-i 
(declare  (salience  -2)) 

(parent2-boundary  ‘^p2-name  ?cl  ?c2  ?p2-data  i) 

=> 

(assert  (parent2-icom  ?p2-name  ?p2-data  input  1)) 

) 
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(defrule  parent2-icom“m 
(declare  (salience  -2)) 

(parent2-boundary  ?p2-name  ?cl  ?c2  ?p2-data  m) 
=> 

(assert  (parent2-icom  ?p2-naine  ?p2~data  mech  1)) 

) 


;  As  the  icom  facts  are  created,  these  rules  will  add  up 
;  the  total  number  of  icom  for  each  activity, 
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(defrule  parent2-control-add 
(declare  (salience  ~3)) 

?f l<-(parent2-icom  ?p2-name  ?datal  control  Tone) 
?f2<-(parent2-icom  ?p2-name  ?data2  control  ?n) 

(test  (neq  Tdatal  ?data2)) 

=> 

(retract  ?fl  ?f2) 

(bind  Ttotal  (+  Tone  Tn)) 

(assert  (parent2~icom  Tp2-'narae  =(gensym)  control  Ttotal)) 

) 


(defrule  parent 2-out put -add 
(declare  (salience  -3)) 

Tf l<-(parent2-icom  Tp2-name  Tdatal  output  Tone) 
Tf2<-(parent2-icom  Tp2-name  Tdata2  output  Tn) 

(test  (neq  Tdatal  Tdata2)) 

=> 

(retract  Tfl  Tf2) 

(bind  Ttotal  (+  Tone  Tn)) 

(assert  (parent2-icom  Tp2-name  =(gensym)  output  Ttotal)) 

) 


(defrule  parent 2- input -add 
(declare  (salience  -3)) 

Tf l<-(parent2-icoro  Tp2-name  Tdatal  input  Tone) 
Tf2<-(parent2-icom  Tp2-name  Tdata2  input  Tn) 

(test  (neq  Tdatal  Tdata2)) 

=> 

(retract  Tfl  Tf2) 

(bind  Ttotal  (+  Tone  Tn)) 

(assert  (par3nt2-icora  Tp2-name  =(gensym)  input  Ttotal)) 

) 
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(delrule  parent2-mech“add 
(declare  (salience  -3)) 

?f  l<-(parent2-icoitt  ?p2-naine  ?datal  raech  ?one) 
?12<-(parent2-icom  ?p2~xiaine  ?data2  mech  ?n) 

(test  (neq  ?datal  ?data2)) 

=> 

(retract  ?fl  712) 

(bind  ?total  (+  Tone  ?n)) 

(assert  (parent 2- icom  ?p2-name  =(gensym)  mech  Ttotal)) 

) 


(defrule  child2-icom“C 
(declaire  (salience  -2)) 

(child2-boundary  ?c2“p2Lrent  ?c2“naine  ?c2-data  c) 

=> 

(assert  (child2-icom  ?c2-parent  ?c2-data  control  1)) 

) 

(delrule  child2“icom-o 
(declare  (salience  -2)) 

(child2-boundary  ?c2-parent  ?c2-name  ?c2-data  o) 

=> 

(assert  (child2-icom  ?c2-parent  ?c2-data  output  1)  ) 

) 

(delrule  child2-icom“i 
(declare  (salience  -2)) 

(child2-boundary  ?c2-paxent  ?c2-name  ?c2-data  i) 

=> 

(assert  (child2“icom  ?c2-parent  ?c2-data  input  1)  ) 

) 

(defrule  child2-icom“m 
(declare  (salience  -2)) 

(child2-boundary  ?c2-parent  ?c2-naine  ?c2“data  m) 

=> 

(assert  (child2-icom  ?c2-parent  ?c2-data  mech  1)  ) 

) 


(defrule  child2-control-add 
(declare  (salience  -3)) 

?f l<-(child2-icom  ?c2-parent  ’datal  control  Tone) 
Tf2<-(child2"icom  Tc2-parent  Tdata2  control  '^n) 
(test  (neq  Tdatal  Tdata2)) 


ai2 


=> 

(retract  ?fl  ?12) 

(bind  ?total  (+  Tone  ?n)) 

(assert  (child2~icom  ?c2-parent  =(gensym)  control  Ttotal)) 

) 


(defrule  child2-output-add 
(declare  (salience  -3)) 

?ll<-(child2~icom  ?c2~parent  Tdatal  output  Tone) 
T12<-(child2-icom  Tc2-parent  Tdata2  output  Tii) 

(test  (neq  Tdatal  Tdata2)) 

=> 

(retract  HI  112) 

(bind  Ttotal  (+  Tone  Tn)) 

(assert  (child2-icom  Tc2“parent  =(gensym)  output  Ttotal)) 

) 


(delrule  child2- input-add 
(declare  (salience  -3)) 

Tll<-(child2-icora  Tc2-parent  Tdatal  input  Tone) 
T12<-(child2-icom  Tc2-parent  Tdata2  input  Tn) 

(test  (neq  Tdatal  Tdata2)) 

=> 

(retract  Til  112) 

(bind  Ttotal  (+  Tone  Tn)) 

(assert  (child2-icom  Tc2-parent  =(gensyin)  input  Ttotal)) 

) 


(defrule  child2-mech-add 
(declare  (salience  -3)) 

Tfl<-(child2-icora  Tc2-pELrent  Tdatal  mech  Tone) 

Tf2<-(child2-icom  Tc2-parent  Tdata2  mech  Tn) 

(test  (neq  Tdatal  Tdata2)) 

=> 

(retract  Tfl  ?f2) 

(bind  Ttotal  (+  Tone  Tn)) 

(assert  (child2-icom  Tc2“parent  =(gensym)  mech  Ttotal)) 

) 

;  Check  Parent  with  2  child  boundary  icom  number  consistency. 

;  If  the  number  of  boundary  icom  for  a  parent  activity  is  not  the  same 
;  with  its  child  activities.  A  warning  will  be  raised. 
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(defrule  chec)c--parent-2child“Control 
(declare  (salience  -6)) 

?ll<-(parent2-icom  ?p2-name  ?  control  ?p) 

?f2<-(child2-icom  ?p2“naine  ?  control  ?c) 

(test  (!=  ?p  ?c)) 

=> 

(retract  7il  ?12) 

(if  (>  ?p  ?c) 
then 

(bind  ?pd  (~  ?p  ?c)) 

(printout  t  '^WARNING,  there  might  be  an  ERROR:  The  niimber  of  boundary  controls**  crll) 
(printout  t  *'  of  parent  activity  *'?p2-name**  is  **?pd*'  control(s)  more  than  **  crll) 

(printout  t  **  its  child  activities.**  crll) 

(printout  t  **  Are  there  * ‘consists  of**  data  items  at  boundary?*'  crll) 

(printout  t  *'  Please  recheck  the  syntax."  crll) 

else 

(bind  ?cd  (-  ?c  ?p)) 

(printout  t  "WARNING,  there  might  be  an  ERROR:  The  number  ol  boundary  controls"  crll) 
(printout  t  **  ol  the  parent  activity  *'?p2‘-name**  is  "Ted"  control(s)  less  "  crll) 
(printout  t  "  than  its  child  boundairy  controls."  crll) 

(printout  t  *'  Are  there  “consists  ol“  data  items  at  boundary?"  crll) 

(printout  t  **  Please  recheck  the  syntax."  crll) 


(delrule  check-parent-2child“Output 
(declare  (salience  -6)) 

?ll<-(p2trent2-icom  ?p2“name  ?  output  ?p) 

?12<-(child2-icom  ?p2-name  ?  output  ?c) 

(test  ( !=  ?p  ?c)) 

=> 

(retract  ?11  ?12) 

(il  (>  ?p  ?c) 
then 

(bind  ?pd  (-  ?p  ?c)) 

(printout  t  "WARNING,  there  might  be  an  ERROR:  The  number  of  boundary  outputs"  crll) 

(printout  t  "  ol  parent  activity  "  ?p2-name  "  is  "  ?pd  "  output(s)  more  "  crll) 

(printout  t  "  than  its  child  activities."  crll) 

(printout  t  "  Are  there  “consists  ol**  data  items  at  boundary?"  crll) 

(printout  t  "  Please  recheck  the  syntax."  crll) 
else 

(bind  ?cd  (-  ?c  ?p)) 

(printout  t  "WARNING,  there  might  be  aui  ERROR:  The  number  of  boundary  outputs"  crll) 

(printout  t  "  ol  the  parent  activity  "  ?p2-name  "  is  "  ?cd  "  output (s)  less  "  crlf) 

(printout  t  "  than  its  child  boundary  outputs."  crlf) 

(printout  t  "  Are  there  “consists  of**  data  items  at  boundary?"  crlf) 

(printout  t  "  Please  recheck  the  syntax."  crlf) 


(defrule  check-par eiit-2child-input 
(declare  (salience  -6)) 

?ll<-(parent2-icom  ?p2-naine  ?  input  ?p) 

?f2<-(child2-icom  ?p2-naine  ?  input  ?c) 

(test  ( !=  ?p  ?c)) 

=> 

(retract  li2) 

(if  (>  ?p  ?c) 
then 

(bind  ?pd  (-  ?p  ?c)) 

(printout  t  "WARNING,  there  might  be  an  ERROR:  The  number  of  boundary  inputs"  crlf) 

(printout  t  "  of  parent  activity  "  ?p2-name  "  is  "  ?pd  "  input(s)  more  "  crlf) 

(printout  t  "  than  its  child  activities."  crlf) 

(printout  t  "  Are  there  * ‘consists  of**  data  items  at  boundetry?"  crlf) 

(printout  t  "  Please  recheck  the  syntax."  crlf) 
else 

(bind  ?cd  (-  ?c  ?p)) 

(printout  t  "WARNING,  there  might  be  an  ERROR:  The  number  of  boundary  inputs"  crlf) 

(printout  t  **  of  the  parent  activity  "  ?p2“name  **  is  **  ?cd  "  input(s)  less  "  crlf) 

(printout  t  *'  than  its  child  boundary  inputs.**  crlf) 

(printout  t  "  Are  there  ‘‘consists  of**  data  items  at  boundary?"  crlf) 

(printout  t  "  Please  recheck  the  syntax."  crlf) 


(defrule  check-parent“2child-mech 
(declare  (salience  -6)) 

?fl<- (parent 2-icom  ?p2-name  ?  mech  ?p) 

?f2<-(child2-icom  ?p2“name  ?  mech  ?c) 

(test  ( !=  ?p  ?c)) 

=> 

(retract  ?fl  ?f2) 

(if  (>  ?p  ?c) 
then 

(bind  ?pd  (-  ?p  ?c)) 

(printout  t  ‘'WARNING,  there  might  be  an  ERROR:  The  number  of  boundary  mechanisms"  crlf) 

(printout  t  "  of  parent  activity  "  ?p2-name  "  is  "  ?pd  "  mechanism(s)  more  **  crlf) 

(printout  t  "  than  its  child  activities."  crlf) 

(printout  t  "  Are  there  ‘‘consists  of**  c*ata  items  at  boundary?"  crlf) 

(printout  t  "  Please  recheck  the  syntax."  crlf) 
else 

(bind  ?cd  (-  ?c  ?p)) 

(printout  t  "WARNING,  there  might  be  an  ERROR:  The  number  of  boundary  mechanisms"  crlf) 

(printout  t  "  of  the  parent  activity  “  ?p2-name  **  is  *'  ?cd  ’*  mechnaism(s)  less  **  crlf) 

(printout  t  "  its  child  child  boundary  mechanisms."  crlf) 

(printout  t  "  Are  there  ‘‘consists  of**  data  items  at  boundary?"  crlf) 

(printout  t  "  Please  recheck  the  syntax."  crlf) 


Those  rules  creating  boundary  facts  for  parents  with 
3  children. 


(defrule  parent-3child 

(declare  (salience  100)) 

?p3fl<-  (act~has“child  ?parent3  Tchildlft^null) 

?p3f2<-  (act-has-child  ?parent3  ?child2lt''?childl&"null) 

?p3f3<-  (act-has-child  ?parent3  ?child3ft''?child2l:*?childl&"null) 
(not  (act-has-child  ?parent3 

?child4&''?child3ft''?child2&''?childl&“'null)  ) 

=> 

(retract  ?p3fl  ?p3f2  ?p3f3) 

(assert  (parents  ?parent3  ?childl  ?child2  ?child3)) 

) 


(defrule  parent 3-boundary 

(parents  ?parent3  ?childl  ?child2  ?child3) 

(icom-tuple  ?parent3  ?p-data  ?p-rel  ?) 

=> 

(assert  (parent 3-boundary  ?parent3  ?p-data  ?p-rel)) 

) 

(defrule  childS-boundary-childl 

(parents  ?parent3  ?childl  ?child2  ?child3) 

(icom-tuple  ?childl  ?cl-data  ?cl-rel  ?) 

=> 

(assert  (childS-boundary  ?parent3  ?childl  ?cl-data  ?cl-rel)) 

) 


(defrule  child3-boundary-child2 

(parents  ?parent3  ?childl  ?child2  ?child3) 

(icom-tuple  ?child2  ?c2-data  ?c2-rel  ?) 

=> 

(assert  (childS-boundary  ?parent3  ?child2  ?c2-data  ?c2-rel)) 

) 

(defrule  child3-boundary-child3 

(parent3  ?parent3  ?childl  ?child2  ?child3) 

(icom-tuple  ?child3  ?c3-data  ?c3-rel  ?) 

=> 

(assert  (childS-boundary  ?parent3  ?child3  ?c3-data  '^cS-rel)) 

) 
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These  2  rules  below  will  erase  the  duplicated  data  element 
in  the: 

(child3“boundary  lacts  , . . . ) 

The  only  possible  data  element  we  want  to  erase  is 

any  data  that  is  shared  by  2  or  3  activities  but  with  different 

icom  code. 

CONDITION: 

1.  Any  two  activities  are  sharing  a  data  element  but 
with  different  icom  relations. 

2.  All  three  activities  are  sharing  a  data  element  but 
with  different  icom  relations. 

With  the  declaration  of  salience,  we  may  assure  that 
any  data  element  shared  by  all  3  child  activities  will  be 
erased  first. 


(defrule  clear~3child-3roid 

?f l<-(child3-boundary  ?parent3  ?childl  ?cl-data  Tcl-rel) 
?f2<“(child3“boundary  ?parent3  ?child2&"?childl  ?cl-data  ?c2-relft''?cl-rel) 
?f3<-(child3-boundary  ?parent3  ?child3&'' ?child2ft'' ? child  1 

?cl“data  ?c3-rel&''?c2-rel&"?cl-rel) 

=> 

(retract  ?fl) 

(retract  ?f2) 

(retract  ?f3) 

) 


If  a  intermediate  arrow  is  the  input  of  one  box  but  also  the 
output  and  input  of  another  two  boxes.  It  must  be  removed  before 
the  arrow  between  the  other  boxes  been  removed. 


(defrule  clear“3child-2mid-l 

(child3“boundary  ?paernt3  ?childl  ?cl-data  ?ci~rel) 

(child3-boundary  ?parent3  ?child2&''?childl  ?cl“data  ?c2-rel&'’?cl-rel) 

?fl<-  (child3~boundary  ?parent3  '^child3&“?child2&“?childl  ?cl“data  '?c3-rel) 
(test  (or  (eq  ?c3-rel  ?c2-rel) 

(eq  ?c3“rel  Tcl-rel))  ) 

=> 

(retract  ?fl) 

) 

(defrule  clear“3child“2mid 
(declare  (salience  -1)) 

?f l<*-(child3-boundary  ?parent3  ?childl  ?cl-data  ?cl-rel) 
?f2<“(child3-boundary  ?parent3  ?child2&''?childl  ?cl-data  ?c2“rel&''"cl--rel) 


=> 

(retract  ?11) 
(retract  ?12) 
) 


;  Remove  the  duplicated  boundary  arrows. 


(defrule  reraove-3child-3boundary 

(child3-boundary  ?parent3  ?childl  ?cl-data  ?cl-rel) 

?±2<-  (child3“boundaLry  ?parent3  ?child2&‘'?childl  ?cl-data  ?cl“rel) 

?f3<-  (child3~boundary  ?parent3  ?child3&''?child2&‘'?childl  Tcl-data  ?cl-rel) 
=> 

(retract  ?f2  ?13) 

) 


(defrule  remove“3child-2boundaary 

(child3-boundary  ?parent3  ?childl  ?cl-data  Tcl-rel) 
?f2<-(child3-bound2Lry  ?parent3  ?child2&“?childl  ?cl-data  ?cl“rel) 
=> 

(retract  ?12) 

) 


(defrule  rid-3child“2consists 
?f l<~(child3-boundary  ?parent3  ?childl  ?cl-data  Tcl-^el) 
?f2<-'(child3~boundary  ?parent3  ?child2&*'?childl  Tc-t-dataft^Tcl-data  ?c2-rel) 
?f3<“(child3-boundary  ?parent3  ?child-p&''?childl&''?child2 

?cp-data&‘'?c2-data&"?cl“data  ?cp-rel&‘'?cl“rel&“'?c2-'rel) 

( consist S“of -name  ?  ?cp-data  ?c2-data) 

(cons ists-of -name  ?  ?cp-data  ?cl-data) 

n> 

(retract  ?fl  ?f2  ?f3) 

) 


;  This  rule  check  a  parent  with  3  child  diagrams  to  see  if  the 
;  parent  boundary  data  are  also  a  part  of  it  child *s  boundary 
;  data. 


(defrule  check-3child-parent 
(declare  (salience  -5)) 

(parentS-boundary  ?p-name  ?p-data  ?p-rel) 
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(not  (consists-of-name  ?  ?p-data  ?c-data)) 

(not  (child3-boundary  ?p-name  ?child3  ?p-data  ?c3-rel)) 


(printout  t  "ERROR:  Data  inconsistency  between  parent  activity 
"?p-naine  "  data  '**  Tp-rel  ***  "  ?p-data  '*  and  its  child 
diagrams."  crll) 

(assert  (syntax-error-occurred)) 

) 


(del rule  check-3child-parent-cons ist s 
(declare  (salience  -6)) 

(parentS-boundary  ?p-name  ?p-data  ?p-rel) 

(cons ist s-of -name  ?  ?p-data  ?c-data) 

(not  (child3-boundary  ?p-name  ?child3  ?c-data  ?c3-iel)) 

=> 

(printout  t  "ERROR:  Data  inconsistency  between  parent  activity 
"?p-n2Lme  "  data  *"  ?p-rel  "  ?p-data  "  and  its  child 
diagrams."  crlf) 

(assert  (syntax-error-occurred)) 

) 


This  rule  check  if  a  parent  with  3  ^hild  diagram  aat 
some  of  them  have  the  some  boundary  data  element  but 
with  different  icom  relation. 

Then  it  is  an  icom  ERROR. 


(defrule  check-3child-icom 
(declare  v^alience  -5)) 

(parent3-boundary  ?p-name  ?p-data  ?p-rel) 

(child3-boundary  ?p-name  ?c-name  ?p-data  ?c-rel) 

(test  (neq  ?p-rel  ?c-rel)) 

=> 

(printout  t  "ERROR:  icom  inconsistency  between  activity  "  crlf) 
(printout  t  "  "?p-name  "  and  its  child  diagram  "  ?c-name"."  crlf) 
(assert  (syntax-error-occur'"ed) ) 

) 


;  This  rule  checks  if  a  child  has  some  boundary  data  element 
;  but  caoi't  find  the  same  data  in  its  parent  then  inconsistency 
;  happened. 


(delrule  check-3child-child 
(declare  (salience  -5)) 

(child3~boundary  ?p~name  ?c-name  ?c-data  ?c-rel) 

(not  (consists-ol-name  ?  ?p-data  ?c-data)) 

(not  (parentS-boundary  ?p-name  ?c-data  ?p-rel)) 

=> 

(printout  t  "ERROR:  Data  inconsistency  between  child  activity 
"  ?c-naine  "  data  Tc-rel  "  ?c-data  "  and  its 
parent,"  crll) 

(assert  (syntax-error-occurred)) 

) 


Parent  with  3  child  diagrams 


The  initial  icom  number  was  build  up  by  this  rule, 


(defrule  parent3-icora-c 
(declare  (salience  -2)) 

(parent3-boundary  ?p3-name  ?p3-data  c) 

=> 

(assert  (parent3-icom  ?p3-name  ?p3-data  control  1)) 

) 

(defrule  parent3-icom-o 
(declare  (salience  -2)) 

(parent 3-boundary  ?p3-name  ?p3-data  o) 

=> 

(assert  (parent3-icom  ?p3-name  ?p3-data  output  1)) 

) 

(defrule  parent3-icom-i 
(declare  (salience  -2)) 

(parent 3-boundary  ?p3-naine  ?p3-data  i) 

=> 

(assert  (parent3-icom  ?p3-name  ?p3-data  input  1)) 

) 

(defrule  parent 3- icom-in 
(declare  (salience  -2)) 

(parentS-boundary  ?p3-name  ?p3-data  m) 

=> 

(assert  (parent3-icom  ?p3-narae  ?p3-data  mech  1)) 

) 


(defrule  parent3-control-add 
(declare  (salience  -3)) 
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?fl<- (parent 3“ icom  ?p3-naine  ?datal  control  ?one) 
?i2<-(parent3-icom  ?p3-name  ?data2  control  ?n) 

(test  (neq  ?datal  ?data2)) 

=> 

(retract  ?11  ?12) 

(bind  ?total  (+  ?one  ?n)) 

(assert  (parent3-icom  ?p3“name  =(gensyro)  control  ?total)) 

) 


(defrule  parent 3-output -add 
(declare  (salience  -3)) 

?ll<-(peu:ent3-icora  ?p3-name  ?datal  output  ?one) 
?f2<-(parent3-iconi  ?p3-name  ?data2  output  ?n) 

(test  (neq  ?datal  ?data2)) 

=> 

(retract  ?fl  ?12) 

(bind  ?total  (+  Tone  ?n)) 

(assert  (parent3-icom  ?p3-najne  =(gensym)  output  Ttotal)) 

) 


(defrule  parent 3- input -add 
(declare  (salience  -3)) 

?f l<-(parent3-icora  ?p3-name  Tdatal  input  Tone) 
Tf2<-(parent3-icora  Tp3-naine  Tdata2  input  Tn) 

(test  (neq  Tdatal  Tdata2)) 

=> 

(retract  Tfl  Tf2) 

(bind  Ttotal  (+  Tone  Tn)) 

(assert  (parent3-icom  Tp3-naine  =(gensym)  input  '^total)) 

) 


(defrule  parentS-mech-add 
(declare  (salience  -3)) 

Tfl<- (parent 3-icora  Tp3-naine  Tdatal  mech  Tone) 
Tf2<-(parent3-icom  Tp3-naine  Tdata2  mech  Tn) 

(test  (neq  Tdatal  Tdata2)) 

=> 

(retract  Tfl  Tf2) 

(bind  Ttotal  (+  Tone  Tn)) 

(assert  (parent3-icom  Tp3-name  =(gensyin)  mech  Ttotal)) 

) 


(defrule  child3-icom-c 
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(declare  (salience  -2)) 

(child3-bonndary  ?c3'-pea:ent  ?c3“name  ?c3-data  c) 

=> 

(assert  (child3-icom  ?c3-parent  ?c3-data  control  1)) 

) 

(defrule  child3-icoin--o 
(declare  (salience  -2)) 

(childS-boundary  ?c3-parent  ?c3“naine  ?c3~data  o) 

=> 

(assert  (child3-icom  ?c3-parent  ?c3-data  output  1)  ) 

) 

(defrule  child3-icom“i 
(declare  (salience  -2)) 

(child3“boundary  ?c3-parent  TcS-name  ?c3-data  i) 

=> 

(assert  (child3-icora  ?c3-parent  ?c3-data  input  1)  ) 

) 

(defrule  child3-icom-m 
(declare  (salience  ~2)) 

(child3-boundary  ?c3-parent  ?c3-nanie  ?c3“data  m) 

=> 

(assert  (chiid3-icom  ?c3~parent  ?c3-data  mech  1)  ) 

) 


(defrule  child3-control“add 
(declare  (salience  -3)) 

?f l<-(child3-icom  ?c3~p£irent  ?datal  control  ?one) 
?f2<-(child3“icom  ?c3-parent  ?data2  control  ?n) 

(test  (neq  ?datal  ?data2)) 

=> 

(retract  ?fl  ?f2) 

(bind  ?total  (+  ?one  ?n)) 

(assert  (child3-icom  ?c3-parent  =(gensym)  control  ?total)) 

) 


(defrule  child3-output-add 
(declare  (salience  -3)) 

?f l<“(child3“icora  ?c3~parent  ?datal  output  Tone) 
?f2<“(child3“icoin  ?c3“parent  ?data2  output  ?n) 

(test  (neq  Tdatal  ?data2)) 

=> 

(retract  ?fl  ?f2) 

(bind  Ttotal  (+  Tone  Tn)) 

(assert  (child3-icom  Tc3"parent  =(gensym)  output  Ttotal)) 
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) 


(defrule  child3-input-add 
(declare  (salience  -3)) 

?ll<-(child3-icom  ?c3-parent  ?datal  input  Tone) 
?12<-(chilaj-icom  ?c3-parent  ?data2  input  ?n) 

(test  (neq  Tdatal  ?data2)) 

=> 

(retract  ?11  ?f2) 

(bind  Ttotal  (+  Tone  Tn)) 

(assert  (child3-icoin  Tc3-parent  =(gensyra)  input  Ttotal)) 

) 


(defrule  child3“mech-add 
(declare  (salience  -3)) 

Tfl<-(child3-icora  Tc3“parent  Tdatal  inech  Tone) 

Tf2<-(child3-icom  Tc3-parent  Tdata2  mech  Tn) 

(test  (neq  Tdatal  Tdata2)) 

=> 

(retract  Tfl  Tf2) 

(bind  Ttotal  (+  Tone  Tn)) 

(assert  (child3-icom  Tc3-'parent  =(gensyro)  mech  Ttotal)) 

) 

;  Check  Parent  with  3  child  boundary  icora  number  consistency 


(defrule  check“parent-3child-control-no-retract 
(declare  fsali»mce  -6)) 

(parent3-icom  TpS-name  T  control  Tp) 

(child3-icoi;i  ?p3“najne  T  control  '^c) 

(test  (!=  Tp  "'c)) 

=> 

(if  (>  Tp  Tc) 
tlien 

(bind  Tpd  (-  Tp  Tc)) 

(printout  t  "WARNING,  there  might  be  an  ERROR:  The  number  of  boundary  controls"  crlf) 
(printout  t  "  of  parent  activity  "Tp3-name"  is  "Tpd"  control(s)  more  than  "  crlf) 

(printout  t  "  its  child  activities.,"  crlf) 

(printout  t  "  Are  there  ** consists  of**  data  items  at  boundary?"  crlf) 

(printout  t  *'  Please  recheck  the  syntax.,"  crlf) 

else 

(bind  Ted  (-  Tc  '^p)) 

(printout  t  "WARNING,  there  might  be  an  ERROR:  The  number  of  boundary  controls"  crlf) 
(printout  t  "  of  the  parent  activity  "?p3-name"  is  *''^cd"  control(s)  less  "  crlf) 
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(printout  t  *'  than  its  child  boundary  controls.'*  crll) 

(printout  t  “  Are  there  “consists  oi**  data  items  at  boundary?"  crlf) 

(printout  t  "  Please  recheck  the  syntax."  crlf) 

)  ) 

(delrule  check~parent“3child~output 
(declare  (salience  ~6)) 

?il<~(parent3-icom  ?p3-name  ?  output  ?p) 

?12<-(child3-icom  ?p3~name  ?  output  ?c) 

(test  (!=  ?p  ?c)) 

=> 

(retract  ?11  ?f2) 

(if  (>  ?p  ?c) 
then 

(bind  ?pd  (-  ?p  ?c)) 

(printout  t  "WARNING,  there  might  be  an  ERROR:  The  number  of  boundary  outputs"  crlf) 

(printout  t  "  of  parent  activity  "  ?p3*-name  "  is  "  ?pd  "  output (s)  more  "  crlf) 

(printout;  t  "  than  its  child  activities."  crlf) 

(printout  t  "  Are  there  “consists  of“  data  items  at  boundary?"  crlf) 

(printout  t  "  Please  recheck  the  syntax."  crlf) 
else 

(bind  ?cd  (-  ?c  ?p)) 

(printout  t  "WARNING,  there  might  be  an  ERROR:  The  number  of  boundary  outputs"  crlf) 

(printout  t  "  of  the  parent  activity  "  ?p3“name  "  is  "  ?cd  "  output(s)  less  "  crlf) 

(printout  t  "  than  its  child  boundary  outputs."  crlf) 

(printout  t  "  Are  there  “consists  of“  data  items  at  boundary?"  crlf) 

(printout  t  "  Please  recheck  the  syntax."  crlf) 


(defrule  check-parent-3child“input 
(declare  (salience  -6)) 

?f l<-(parent3-icora  ?p3“name  ?  input  ?p) 

?f2<-(child3-icom  ?p3-name  ?  input  ?c) 

(test  ( !=  ?p  ?c)) 

=> 

(retract  ?fl  ?f2) 

(if  (>  ?p  ?c) 
then 

(bind  ?pd  (-  ?p  ?c)) 

(printout  t  "WARNING,  there  might  be  an  ERROR;  The  number  of  boundary  inputs"  crlf) 
(printout  t  "  of  parent  activity  "  ?p3-name  "  is  "  ?pd  "  input(s)  more  "  crlf) 
(printout  t  "  than  its  child  activities."  crlf) 

(printout  t  "  Are  there  “consists  of^'  data  items  at  boundary?"  crlf) 

(printout  t  "  Please  recheck  the  syntax."  crlf) 
else 

(bind  ?cd  ?c  ?p)) 

(printout  t  "WARNING,  there  might  be  an  ERROR:  The  number  of  boundary  inputs"  crlf) 
(printout  t  "  of  the  parent  activity  "  ?p3“name  "  is  "  ?cd  "  input (s)  less  "  crlf) 
(printout  t  "  than  its  child  boundary  inputs."  crlf) 

(printout  t  "  Are  there  “consists  of“  data  items  at  boundary?"  crlf) 

(printout  t  "  Please  locheck  the  syntax."  crlf) 
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)  ) 


(defrule  chdck-parent*3child-mech 
(declare  (salience  -6}} 
?fl<-(parent3“icom  ?p3*-name  ?  mech  ?p) 
?12<-(child3"icom  ?p3“naine  ?  mech  ?c) 
(test  (1=  ?p  ?c)) 

=> 


(retract  ?il 
Hi  (>  ?p  ?c) 
xhen 

(bind  ?pd  (- 
(printout  t  ' 
(printout 
(printout 
(printout 
(printout 
else 

(bind  ?cd 
(printout 
(printout 
(printout 
(printout 
(printout 

)  ) 


?f2) 


?p  ?c)) 

WARNING,  there  might  be  an  ERROR:  The  number  of  bv^-indary  mechanisms'*  crlf) 
t  "  of  parent  activity  "  ?p3-name  "  is  "  ?pcl 
t  "  than  its  child  activities,"  crlf) 

t  "  Are  there  ‘‘consists  of**  data  items  at  boundary?"  crlf) 
t  "  Please  recheck  the  syntax."  crlf) 


mechanism(s)  more  "  crlf) 


(-  ?c  ?p)) 

t  "WARNING,  there  might  be  an  ERROR:  The  number  of 
t  "  of  the  parent  activity  "  ?p3"name  "  is  "  ?cd 
t  "  its  child  child  boundary  mechanisms."  crlf) 
t  "  Are  there  “consists  of**  data  items  at  boundary?"  crlf) 
t  "  Please  recheck  the  syntax."  crlf) 


boundary  mechanisms"  crlf) 
mechnaism(s)  less  "  crlf) 


>  >  1 1 1  >  I )  1 1 » )  *  I » 1 1 » » ,  >  >  1 1 » » I  > » » >  I  >  >  I  >  I )  I  f  > )  f » I » 1 1 » I » , , , , , ,  1 1 , , ,  f  I , , , , 

:  This  rule  will  create  the  boundary  facts  for  activities  having 
;  4  child  diagrams. 


(defrule  parent-4child 
(declare  (salience  100) ) 

?pfl<“  (act-has-child  ?parent4  ?childl&*null) 

?pf2<“  (act-has-child  ?parent4  ?child2&“?childl&''null) 

?pf3<-  (act-has-child  ?parent4  ?child3&'’?child2&''?childl&‘'null) 
?pf4<-  (act-has-child  ?parent4 

?child4A*'?child3&'?child2fc''?childl&’'null) 

(not  (act-has-child  ?parent4 

?child5&''?child4&''?child3&"?child2A^?childl&''null)  ) 

=> 

(retract  ?pfl  ?pf2  ?pf3  ?pf4) 

(assert  (parent4  ?parent4  ?childl  ?child2  ?child3  ?child4)) 

) 

(defrule  parent4-boundary 

(parent4  ?paa:ent4  ?childl  ?child2  ?child3  ?child4) 

(icora-tuple  ?parent4  ?p-data  ?p-rel  ?) 

=> 

(assert  (parent4-boundary  ?parent4  ?p-data  ?p-rel)) 
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) 


(delrule  child4‘-boundary-childl 
(par6nt4  ?paar6nt4  ?childl  ?child2  ?child3  ?child4) 

(icom-tupla  ?childl  ?cl-data  Tcl-rel  ?) 

=> 

(assert  (child4-boundary  ?parent4  ?childl  ?cl-data  ?cl*-rel)) 

) 

(defrule  child4-boundary“Child2 

(parent4  ?parent4  ?childl  ?child2  ?child3  ?child4) 

(icom-tuple  ?child2  ?c2-data  ?c2~rel  ?) 

=> 

(assert  (child4-boundary  ?parent4  ?child2  ?c2-data  ?c2“r6l)) 

) 

(delrule  child4-boundary-child3 

(parent4  ?parent4  ?childl  ?child2  ?child3  ?child4) 

(icora-tuple  ?child3  ?c3-data  ?c3“rel  ?) 

=> 

(assert  (child4-boundary  ?parent4  ?child3  ?c3-data  ?c3-rel)) 

) 

(delrule  child4-boundary-child4 

(parent4  ?parent4  ?childl  ?child2  ?child3  ?child4) 

(icoro-tuple  ?child4  ?c4-data  ?c4-rel  ?) 

=> 

(assert  (child4-boundary  ?parent4  ?child4  ?c4”data  ?c4-rel)) 

) 


These  rules  will  clear  the  duplicated  boundary  facts  in  the  facts 
created  by  the  previous  rule. 

CONDITION: 

1.  3  activities  out  of  4  sharing  a  same  data 

2.  2  activities  out  of  4  sharing  a  same  data 

3.  all  4  activities  are  sharing  a  same  data 
element  but  with  different  icom  code 

Condition  3  is  not  likely  to  happen,  so  it  is  not  implemented 


(defrule  clear“4child-3mid 

?f l<“(child4-boundary  ?parent4  ?childl  ?cl-data  ?cl--rel) 

?f 2<-(child4“boundary  ?parent4  ?child2&''?childl  ?cl-data  ?c2“rel&''?cl-rel) 
?f3<-(child4-boundary  ?parent4  ?child3&''?child2&''?childl  ?cl-data 

?c3-rel&‘’?c2-rel&''?cl~rel) 

=> 

(retract  ?fl) 
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(retract  ?12) 
(retract  ?t3) 
) 


If  a  intermediate  arrow  is  the  input  of  one  box  but  also  the 
output  and  input  of  another  two  boxes.  It  must  be  removed  before 
the  arrow  between  the  other  boxes  been  removed. 


(defrule  clear“4child-2mid*l 

(child4~boundary  ?paernt4  ?childl  Tcl^-data  Tcl-rel) 

(child4~boundary  ?parent4  ?child2ft"?childl  ?cl-data  ?c2-rel&"?cl-rel) 

?fl<-  (child4-boundary  ?parent4  ?child3ft‘’?child2ft"?childl  ?cl-data  ?c3-rel) 
(test  (or  (eq  ?c3~rel  ?c2"rel) 

(eq  ?c3-rel  ?cl-rel))  ) 

s:> 

(retract  ?11) 

) 


(defrule  clear-4child-2mid 
(declare  (salience  -1)) 

?f l<-(child4-boundary  ?parent4  ?childl  ?cl-data  ?cl-rel) 
?f2<~(child4“boundary  ?parent4  ?child2&"?childl  ?cl~data  ?c2--rel&'’?cl-rel) 
=> 

(retract  ?il) 

(retract  ?f2) 

) 


;  Remove  the  duplicated  boundary  arrows  for  parents  with 
;  with  4  child  diagrams .  Consider  that  at  most  3  child 
;  out  of  4  might  use  the  same  data. 


(defrule  remove-4child-3boundary 

(child4-boundary  ?parent4  ?childl  ?cl“data  ?cl~rel) 

?f2<-  (child4-boundary  ?parent4  ?child2&"?childl  ?cl-*data  ?cl-rel) 

?f3<-‘  (child4-boundary  ?parent4  ?child3&“?child2l:''?childl  ?cl“data  ?cl-rel) 
=> 

(retract  ?f2  ?f3) 

) 

(defrule  reroove-4child-2boundary 

(child4-boundciry  ?parent4  ?childl  ?c 1-data  ?cl-rel) 
?f2<-(child4-boundary  ?parent4  ?child2&‘'?childl  ?cl-data  ?cl-rel) 
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=> 

(retract  ?f2) 

) 


;  This  rule  will  get  rid  of  consists  of  intermediate  data  relations 
;  that  a  data  has  3  subcomponents. 


(defrule  rid“4child-3consists 

?f l<-(child4-boundary  ?parent4  Tchildl  ?cl"data  ?cl-rel) 

?f2<“(child4~boundary  ?parent4  ?child2l:‘'?childl  ?c2-dataft‘'?cl~data  ?c2“rel) 
?f3<-*(child4-boundary  ?parent4  ?child3k‘'?child2t"?childl  ?c3--datalt'’?c2~data&“?cl-data  ?c3-rel) 
?f4<“(child4~boundary  ?parent4  ?child“pk*?child3k"?child2ft"?childl 

?cp"data&‘*?c3-datak''?c2-datak"?cl-data  ?cp-relf  ?c3-relk''?c2-rel&''?cl-rel) 
(consists-of-name  ?  ?cp“data  ?c3-data) 

(consistS“Of~name  ?  ?cp~data  ?c2~data) 

( cons ists-of -name  ?  ?cp-data  ?cl-data) 

=> 

(retract  ?fl) 

(retract  ?f2) 

(retract  ?f3) 

(retract  ?f4) 

) 


This  rule  should  fired  later  than  “3consists;  since  if 
2  of  3  consists  facts  are  retracted,  the  remaining  one  will  not 
be  matched  to  be  retracted. 


(defrule  rid-4child-2consists 
(declare  (salience  -1)) 

?f l<-(child4-boundary  ?parent4  ?childl  ?cl-data  ?cl-rel) 

?f2<-(child4-boundary  ?parent4  ?child2&''?childl  ?c2-data&"?c 1-data  ?c2-rel) 
?f3<-(child4-boundary  ?parent4  ?child-p&‘'?child2&''?childl 

?cp-data&''?c2-data&''?cl-data  ?cp-rel&'’?c2-rel&”?cl-rel) 
( cons ists-of -name  ?  ?cp-data  ?c2-data) 

(cons ists-of -name  ?  ?cp-data  ?cl-data) 

=> 

(retract  '^fl  '?f2  ?f3) 

) 


This  rule  check  a  parent  activity  with  4  child  diagram  to  see  if 
there  are  any  boundary  data  belonging  to  the  parent  but  not  a  part  of 
the  child  diagrams. 


(defrule  check-4ch ’.Id-parent 
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(declare  (salience  -5)) 

(parent4-boundary  ?p-naine  ?p-data  Tp-rel) 

(not  (consists-ol-name  ?  ?p“data  ?c-data)) 

(not  (child4“boundary  ?p-nanie  ?child4  ?p-data  ?c4-rel)) 

=> 

(printout  t  "ERROR:  Data  inconsistency  between  parent  activity 
"?p-naine  "  data  ?p-rel  "  ?p-data  "  and  its  child 
diagrams."  crlf) 

(assert  (syntax-error-occurred)) 

) 

(defrule  check-4child-parent-consists 
(declare  (salience  -6)) 

(parent4-boundary  ?p-name  ?p-data  ?p-rel) 

(consists-ol-name  ?  ?p-data  ?c-data) 

(not  (child4-boundary  ?p-name  ?child4  ?c-data  ?c4-rel)) 

=> 

(printout  t  "ERROR:  Data  inconsistency  between  parent  activity 
"?p-name  "  data  *"  ?p-rel  "  ?p-data  "  and  its  child 
diagrams."  crll) 

(assert  (syntax-error-occurred)) 

) 


This  rule  checks  il  a  parent  with  4  child  diagrams  that 
some  of  them  have  the  same  boundary  data  element  but 
with  different  icom  relation  in  contrast  with  their  parent. 
Then  it  is  an  icom  ERROR. 


(defrule  check-4child-icom 
(declare  (salience  -5)) 

(parent4“boundary  ?p-naine  ?p-data  ?p-rel) 

(child4“boundary  ?p-namf  Tc-name  ?p-data  ?c-rel) 

(test  (neq  ?p-rel  ?c-rel)) 

=> 

(printout  t  "ERROR:  icom  inconsistency  between  activity  " 
?P“name  "  and  its  child  diagrcon  " 

?c-narae  crlf) 

(assert  (syntax-error-occurred)) 

) 


9999999999999999999999999999999999999999999999999999999999999999 

This  rule  checks  if  a  parent  have  4  child,  and  there  is  some 
boundary  data  element  in  the  child  diagrams 

but  can^t  find  the  same  data  in  their  parent  then  inconsistency 
happened. 
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(defrule  check-4child-child 
(declare  (salience  -5)) 
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(child4~bouiidary  Tp-name  ?c-name  ?c~data  ?c-rel) 

(not  (consists-ol-name  ?  ?p-data  ?C“data)) 

(not  (parent4-boundary  Tp-name  ?c-data  Tp-rel)) 

=> 

(printout  t  "ERROR:  Data  inconsistency  between  child  activity 
**  ?c-naine  "  data  ?c-rel  ***  "  ?c-data  "  and  its 
parent."  crll) 

(assert  (syntax-error-occurred)) 

) 


Parent  with  4  child  diagrams 


The  initial  icom  number  was  build  up  by  this  rule. 


(defrule  parent4-icom-c 
(declare  (salience  -2)) 

(parent4-boundary  ?p4-name  ?p4-data  c) 

=> 

(assert  (parent4-icom  ?p4-name  ?p4-data  control  1)) 

) 

(deirule  parent4-icom“0 
(declare  (salience  -2)) 

(parent4-boundary  ?p4-name  ?p4-data  o) 

=> 

(assert  (parent4-icom  ?p4-name  ?p4-data  output  1)) 

) 

(defrule  parent4-icom-i 
(declare  (salience  -2)) 

(parent4-boundary  ?p4-name  ?p4-data  i) 

=> 

(assert  (parent4-icom  ?p4-name  ?p4-data  input  1)) 

) 

(defrule  parent4-icom-m 
(declare  (salience  -2)) 

(parent4-boundary  ?p4-name  ?p4-data  m) 

=> 

(assert  (parent4-icom  ?p4-name  ?p4-data  mech  1)) 

) 


(defrule  par ent4- control-add 
(declare  (salience  -3)) 

?fl<-(parent4-icom  ?p4-name  ?datal  control  Tone) 
?f2<-(parent4-icom  ?p4-name  ?data2  control  ?n) 
(test  (neq  Tdatal  ?data2)) 
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=> 

(retract  ?11  ?12) 

(bind  ?total  (+  ?one  ?n)) 

(assert  (parent4~icom  ?p4~naiiie  =(gensyra)  control  ?total)) 

) 


(defrule  parent4“OUtput-add 
(declare  (salience  -3)) 

?ll<~(parent4-icora  ?p4“naine  ?datal  output  ?one) 
?12<-(parent4~icom  ?p4-name  ?data2  output  ?n) 

(test  (neq  ?datal  ?data2)) 

=> 

(retract  ?fl  ?12) 

(bind  ?total  (+  ?one  ?n)) 

(assert  (parent4-icom  ?p4-naine  =(gensym)  output  ?total)) 

) 


(defrule  peLrent4- input- add 
(declare  (salience  -3)) 

?fl<-(parent4-icom  ?p4-name  ?datal  input  ?one) 
?f2<-(parent4-icom  ?p4-name  ?data2  input  ?n) 

(test  (neq  ?datal  ?data2)) 

=> 

(retract  ?fl  ?f2) 

(bind  ?total  (+  ?one  ?n)) 

(assert  (parent4-icom  ?p4-naine  =(gensym)  input  ?total)) 

) 


(defrule  p2arent4-mech-add 
(declare  (salience  -3)) 

?f l<-(parent4-icom  ?p4-naine  ?datal  ?mech  ?one) 
?f2<-(parent4-icoin  ?p4-name  ?data2  ?mech  ?n) 

(test  (neq  ?datal  ?data2)) 

=> 

(retract  ?fl  ?f2) 

(bind  ?total  (+  ?one  ?n)) 

(assert  (parent4-icom  ?p4-naine  =(gensym)  mech  ?total)) 

) 


(defrule  child4-icoin-c 
(declare  (salience  -2)) 

(child4-boundary  ?c4-parent  '^c4-name  ?c4-data  c) 
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=> 

(assert  {child4-icom  ?c4-parent  ?c4-data  control  1)) 

) 

(defrule  child4“icom-o 
(declare  (salience  -2)) 

(child4-boundary  ?c4-parent  ?c4-naine  ?c4“data  o) 

=> 

(assert  (child4-icom  ?c4“parent  ?c4-data  output  1)  ) 

) 

(defrule  child4-icom“i 
(declare  (salience  -2)) 

(child4“boundary  ?c4-parent  ?c4  -name  ?c4“data  i) 

=> 

(assert  (child4-icom  ?c4-parent  ?c4*"data  input  1)  ) 

) 

(defrule  child4-icom-m 
(declare  (salience  -2)) 

(child4-boundary  ?c4“parent  ?c4-name  ?c4-data  ra) 

=> 

(assert  (child4-icom  ?c4“parent  ?c4“data  mech  1)  ) 

) 


(defrule  child4“Control-add 
(declare  (salience  -3)) 

?f l<-(child4-icom  ?c4“parent  ?datal  control  ?one) 
?f2<-(child4-icom  ?c4“parent  ?data2  control  ?n) 

(test  (neq  ?datal  ?data2)) 

=> 

(retract  ?fl  ?f2) 

(bind  ?total  (+  ?one  ?n)) 

(assert  (child4“icom  ?c4-parent  =(gensym)  control  ?total)) 

) 


(defrule  child4-output-add 
(declare  (salience  -3)) 

?f l<-(child4-icora  ?c4-parent  ?datal  output  ?one) 
?f2<*-(child4-icoro  ?c4“parent  ?data2  output  ?n) 

(test  (neq  ?datal  ?data2)) 

=> 

(retract  ?fl  ?f2) 

(bind  ?total  (+  ?one  ?n)) 

(assert  (child4-icom  ?c4-parent  =(gensym)  output  Ttotal)) 


C-32 


) 


(delrule  child4-input-add 
(declare  (salience  -3)) 

?fl<-(child4“icom  ?c4“parent  ?datal  input  ?one) 
?12<-(child4-icom  ?c4-parent  ?data2  input  ?n) 

(test  (neq  ?datal  ?data2)) 

=> 

(retract  111  ?i2) 

(bind  ?total  (+  Tone  ?n)) 

(assert  (child4-icom  ?c4-paLrent  =(gensym)  input  Ttotal)) 

) 


(defrule  child4“niech“add 
(declare  (salience  -3)) 

?fl<~(child4-’icoia  ?c4“parent  Tdatal  mech  Tone) 
T12<“(child4-icom  Tc4~parent  Tdata2  mech  Tn) 

(test  (neq  Tdatal  Tdata2)) 

=> 

(retract  Til  T12) 

(bind  Ttotal  (+  Tone  Tn)) 

(assert  (child4-icom  Tc4“parent  =(gensym)  mech  Ttotal)) 

) 


4e  %  %  4c  Jfc  4c  4c  ]|e  4c  1 ic  %  4c  4e  t  4c  3|c  4c  4c  )|c  1 4c  4e  ]|t  )|c  4c  %  :|c  4c })(:(( 1 :|(  3|c  :(c  4c  ]|c  4e  t  %  If  4c  ]|c  ]|e  4c  4c  :|c  ^  3ie  9|c  3|c  i|c  4c 

Check  Parent  with  4  child  boundary  icom  number  consistancy 


(defrule  check“parent-4child-control 
(declare  (salience  -6)) 

Tf l<~(parent4-icom  Tp4-name  T  control  Tp) 

Tf2<-(child4-icom  Tp4-name  T  control  Tc) 

(test  (1=  Tp  Tc)) 

=> 

(retract  Tfl  Tf2) 

(if  (>  Tp  Tc) 
then 

(bind  Tpd  (-  Tp  Tc)) 

(printout  t  "WARNING,  there  might  be  an  ERROR:  The  number  of  boundary  controls"  crlf) 
(printout  t  "  of  parent  activity  "Tp4-naine"  is  "Tpd"  control (s)  more  thaui  "  crlf) 

(printout  t  "  its  child  activities."  crlf) 

(printout  t  "  Are  there  ‘‘consists  of**  data  items  at  boundary"^"  crlf) 

(printout  t  "  Please  recheck  the  syntax.**  crlf) 

else 

(bind  Ted  (-  Tc  Tp)) 
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(printout  t  "WARNING,  there  might  be  an  ERROR:  The  number  of  boundary  controls"  crlf) 
(printout  t  "  of  the  parent  activity  "?p4*-name"  is  "?cd"  control(s)  less  "  crlf) 
(printout  t  "  than  its  child  boundary  controls."  crlf) 

(printout  t  "  Are  there  * ‘consists  of*^  data  items  at  boundary?"  crlf) 

(printout  t  "  Please  recheck  the  syntax."  crlf) 


)  ) 


(defrule  check-parent“4child-output 
(declare  (salience  -6)) 

?f l<-(parent4-icom  ?p4-name  ?  output  ?p) 

?f2<-(child4“icom  ?p4-name  ?  output  ?c) 

(test  (!=  ?p  ?c)) 

=> 

(retract  ?fl  ?f2) 

(if  (>  ?p  ?c) 
then 

(bind  ?pd  (-  ?p  ?c)) 

(printout  t  "WARNING,  there  might  be  an  ERROR:  The  number  of  boundary  outputs"  crlf) 
of  parent  activity  "  ?p4"name  "  is  "  ?pd  "  output (s)  more  "  crlf) 
than  its  child  activities."  crlf) 

Are  there  * ‘consists  of**  data  items  at  boundary?"  crlf) 

Please  recheck  the  syntax."  crlf) 


(printout 
(printout 
(printout 
(printout 
else 

(bind  ?cd  (-  ?c  ?p)) 


(printout 
(printout 
(printout 
(printout 
(printout 
)  ) 


t  "WARNING,  there  might  be  an  ERROR:  The  number  of 
t  "  of  the  parent  activity  "  ?p4-naroe  "  is  "  ?cd 
t  "  than  its  child  boundary  outputs."  crlf) 
t  "  Are  there  ‘‘consists  of**  data  items  at  boundary?"  crlf) 
t  "  Please  recheck  the  syntax."  crlf) 


boundary  outputs"  crlf) 
output (s)  less  "  crlf) 


(defrule  check-par ent-4child- input 
(declare  (salience  -6)) 

?f l<-(parent4-icom  ?p4-naane  ?  input  ?p) 

?f2<-(child4-icom  ?p4-name  ?  input  ?c) 

(test  ( 1=  ?p  ?c)) 

=> 

(retract  ?fl  ?f2) 

(if  (>  ?p  ?c) 
then 

(bind  ?pd  (-  ?p  ?c)) 

(printout  t  "WARNING,  there  might  be  an  ERROR:  The  number  of  boundary  inputs"  crlf) 
(printout  t  "  oi  parent  activity  "  ?p4-name  "  is  "  ?pd  "  input (s)  more  "  crlf) 
(printout  t  "  than  its  child  activities."  crlf) 

(printout  t  "  Are  there  ‘‘consists  of**  data  items  at  boundary*^"  crlf) 

(printout  t  "  Please  recheck  the  syntax."  crlf) 
else 

(bind  ?cd  (-  ?c  ?p)) 

(printout  t  "WARNING,  there  might  be  an  ERROR:  The  number  of  boundary  inputs"  crlf) 
(printout  t  "  of  the  parent  activity  ”  ?p4-name  "  is  "  ?cd  "  input (s)  less  "  crlf) 
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(printout  t  ”  thain  its  child  boundary  inputs.”  crlf) 

(printout  t  ”  Are  there  * ‘consists  of**  data  items  at  boundary?”  crlf) 
(printout  t  ”  Please  recheck  the  syntax."  crlf) 


mech  ?p) 
mech  ?c) 


(defrule  check-par ent-4child~mech 
(declare  (salience  -6)) 

?fl<-(parent4-icom  ?p4-name  ? 

?f2<-(child4-icom  ?p4-name  ? 

(test  (!=  ?p  ?c)) 

=> 

(retract  ?fl  ?f2) 

(if  (>  ?p  ?c) 
then 

(bind  ?pd  (-  ?p  ?c)) 

(printout  t  "WARNING,  there  might  be  an  ERROR:  The  number  of  boundary  mechanisms”  crlf) 


)  ) 


(printout 
(printout 
(printout 
(printout 
else 

(bind  ?cd  ( 
(printout 
(printout 
(printout 
(printout 
(printout 


?pd  ”  mechanism(s)  more  ”  crlf) 


of  paorent  activity  "  ?p4-name  "  is 
than  its  child  activities."  crlf) 

Are  there  “consists  of**  data  items  at  boundary?”  crlf) 
Please  recheck  the  syntax."  crlf) 


?c  ?p)) 

t  "WARNING,  there  might  be  an  ERROR:  The  number  of 
t 
t 
t 
t 


boundary  mechanisms”  crlf) 
of  the  parent  activity  "  ?p4-name  "  is  "  ?cd  "  mechnaism(s)  less  "  crlf) 
its  child  child  boundary  mechanisms."  crlf) 

Are  there  “consists  of**  data  items  at  boundary?”  crlf) 

Please  recheck  the  syntax."  crlf) 


;  This  rule  will  create  the  boundary  facts  for  activities  having 
;  5  child  diagrams. 


(defrule  parent-Schild 
(declare  (salience  100)) 

?f l<-(act-has-child  ?parent5  ?childl&'’null) 

?f2<-(act-has-child  ?parent5  ?child2&'?childl&~null) 
?f3<-(act-has-child  ?parent5  ?child3ft'"?child2&"'?chi]dl&''null) 
?f4<-(act-has-child  ?parent5 

?child4&''?child3&“?child2&“?childl&‘'null) 
?f5<-(act-has-child  ?parent5 

?child5&''?child4&‘'?child3&“?child2&''?childl&^null) 
(not  (act-has-child  ?parent5 
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?child6&“?child5&*?child4&''?child3ft“?child2&''?childl&'*null)  ) 

=> 

(retract  ?fl  ?f2  ?f3  ?f4  ?f5) 

(assert  (parents  ?parent6  ?childl  ?child2  ?child3  ?child4  ?child6)) 

) 

(delrule  parentS-boundary 

(parents  TparentS  Tchildl  ?child2  ?child3  ?child4  TchildS) 

(icom-tuple  ?parentS  ?p-data  ?p-rel  ?) 

=> 

(assert  (parentS-boundary  ?parentS  ?p“data  Tp-rel)) 

) 

(defrule  childS-boundary-childl 

(parents  ?parentS  ?childl  ?child2  ?child3  ?child4  TchildS) 

(icom-tuple  ?childl  ?cl-data  ?cl-rel  ?) 

=> 

(assert  (childS-boundary  ?parentS  ?childl  ?cl-data  ?cl-rel)) 

) 

(defrule  childS-boundary-child2 

(parents  ?parentS  Tchildl  ?child2  ?child3  ?child4  ?child5) 

(icom-tuple  ?child2  ?c2-data  ?c2-rel  ?) 

=> 

(assert  (childS-boundary  ?parentS  '?child2  ?c2-data  ?c2-rel)) 

) 

(defrule  childS-boundary-child3 

(parents  ?parent5  ?childl  ?child2  ?child3  ?child4  ?child5) 

(icom-tuple  ?child3  ?c3-data  ?c3-rel  ?) 

=> 

(assert  (childS-boundary  TparentS  ?child3  ?c3-data  ?c3-rel)) 

) 


(defrule  child5-boundary-child4 

(parents  ?parent5  ?childl  ?child2  ?child3  . child4  ?child5) 
(icom-tuple  ?child4  ?c4-data  ?c4-rel  '^) 

=> 

(assert  (childS-boundary  ?parent5  ?child4  ?c4-data  ?c4-rel)) 

) 

(defrule  childS-boundary-childS 

(parents  ?parent5  ?childl  ?child2  ?child3  '?child4  ?child5) 
(icom-tuple  ?childS  '^cS-data  ?c5-rel  ?) 

=> 

(assert  (childS-boundary  '^parents  ’childS  ?c5-data  ?c5-rel)) 

) 
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These  rules  will  clear  the  duplicated  boundary  facts  in  the  facts 
created  by  the  previous  rule. 

CONDITION: 

1.  4  activities  out  of  5  sharing  a  same  data 

2.  3  activities  out  of  S  sharing  a  same  data 

3.  2  activities  out  of  5  sharing  a  same  data 

4.  all  5  activities  are  sharing  a  same  data 

element  but  with  different  icom  code 

Condition  1  and  4  is  not  likely  to  happen,  so  it  is  not  implemented 


(defrule  clear-Schild-Smid 

?f  l<“(child6-boundary  ?parent5  ?childl  ?cl-data  ?cl*-rel) 

?f2<“(child5-boundary  ?parent5  ?child2ft''?childl  ?cl-data  ?c2-rel&‘'?cl“rel) 
?f3<-(child5-boundary  ?parent5  ?child3ft*?child2f ?childl  ?cl-data 

?c3-rel&''?c2-relft‘'?cl-rel) 

=> 

(retract  ?fl) 

(retract  ?f2) 

(retract  ?f3) 

) 

;  If  a  intermediate  arrow  is  the  input  of  one  box  but  also  the 
;  output  and  input  of  another  two  boxes.  It  must  be  removed  before 
;  the  etrrow  between  the  other  boxes  been  removed* 


(defrule  cl ezur-S child- 2mid-l 

(childS-boundary  ?paernt5  ? child 1  ?c 1-data  ?cl-rel) 

(childS-boundary  ?parent5  ?child2&"?childl  ?cl-data  ?c2-rel&'’?cl-rel) 

?fl<-  (childS-boundary  ?parent5  ?child3&‘'?child2k"? child 1  ?cl-data  ?c3-rel) 
(test  (or  (eq  ?c3-rel  ?c2-rel) 

(eq  ?c3-rel  ?cl-rel))  ) 

=> 

(retract  ?fl) 

) 


(defrule  clear-5child-2mid 
(declare  (salience  -1)) 

?fl<-( childS-boundary  ?parentS  ?childl  ?cl-data  ?cl-rel) 

?f2<-( childS-boundary  ?parent6  ?child2&‘'?childl  ?cl-data  ?c2-rel&‘’?cl-rel) 
=> 

(retract  ?fl) 

(retract  ?f2) 

) 
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;  Remove  the  duplicated  boundary  arrows  lor  parents  with 
;  with  5  child  diagrams.  Consider  that  at  most  3  child 
;  out  of  5  might  use  the  same  data. 


(delrule  remove-Schild-Sboundary 

(childS-boundary  ?parent5  ?childl  ?cl~data  ?cl-“rel) 

?f2<-  (childS-boundary  ?parent6  ?child2&‘*?childl  ?cl-data  ?cl-rel) 

?13<-  (childS-boundary  ?parent6  ?child3fc*?child2&'’?childl  ?cl“data  ?cl~rel) 
=> 

(retract  ?12  ?13) 

) 

(delrule  remove“5child-2boundary 

(childS-boundary  ?parent6  ?childl  ?cl-data  Tcl-rel) 

?12<-(child5-boundary  ?parent5  ?child2&''?childl  ?cl-data  Tcl-rel) 

=> 

(retract  ?12) 

) 


(delrule  rid“5child~3consists 

?ll<”(child5“boundary  ?parent5  ?childl  ?cl-data  ?cl-rel) 

?12<-(child6-boundary  ?parent5  ?child2&‘'?childl  ?c2"data&‘'?cl-data  ?c2“-rel) 

?13<-(child5-'boundary  ?parent5  ?child3&'’?child2ft''?childl 

?c3-data&''?c2-data&‘'?cl“data  ?c3-rel) 
?14<“(child5“boundary  ?parent6  ?child"p&"?child3&''?child2&"'?childl 

?cp-data&"?c3-dataft'‘?c2-data&"?cl-data  ?cp-rel&“?c3-rel&''?c2"rel&"?cl-rel) 

( consist s-ol -name  ?  ?cp-data  ?c3-data) 

(consists-ol-name  ?  ?cp-data  ?c2-data) 

(consists-ol-name  ?  ?cp-data  ?cl“data) 

=> 

(retract  ?11) 

(retract  ?12) 

(retract  ?13) 

(retract  ?14) 

) 

(delrule  rid“5child-2consists 
(declare  (salience  -1)) 

?ll<-(child5-boundary  ?parent6  ?childl  ?cl-data  Tcl-rel) 

?12<-(child5-boundary  ?parent5  ?child2&“?childl  ?c2-data&‘’?cl-data  ?c2-rel) 
?13<-(child6“boundary  ?parent5  ?child-p&*’?child2&''?childl  ?cp“data&‘’?c2-data&''?c  1-data 

?cp“rel&''?c2-rel&''?cl-rel) 

(consists-ol-name  ?  ?cp-data  ?c2“data) 

(consists-ol-name  ?  ?cp-data  ?cl-data) 

=> 

(retract  ?11  ?12  ?f3) 

) 
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;  This  rule  check  a  parent  activity  with  6  child  diagram  to  see  il 
;  there  are  any  boundary  data  belonging  to  the  parent  but  not  a  part  oi 
;  the  child  diagrams. 


(defrule  check-Schild-parent 
(declare  (salience  -6)) 

(parentS-boundary  ?p-name  ?p-data  ?p-rel) 

(not  (consists-ol-name  ?  ?p~data  ?c-data)) 

(not  (childS-boundary  ?p-naroe  ?child5  ?p-data  ?c5“rel)) 

=> 

(printout  t  "ERROR:  Data  inconsistency  between  parent  activity 
"?P“name  "  data  ***  ?p~rel  "  ?p-data  "  and  its  child 
diagrams."  crll) 

(assert  (syntsuc-error-occurred)) 

) 


(defrule  check-5child~parent-consists 
(declare  (salience  -6)) 

(parentS-boundary  ?p“name  ?p-data  ?p-rel) 

(consists-of-name  ?  ?p-data  ?C“data) 

(not  (childS-boundary  ?p-narae  ?child5  ?c-data  ?c5-rel)) 

=> 

(printout  t  "ERROR:  Data  inconsistency  between  parent  activity 
"?p-name  "  data  ?p-rel  "  ?p-data  "  and  its  child 
diagrams."  crlf) 

(assert  (syntax-error-occurred)) 

) 


This  rule  checks  if  a  parent  with  6  child  diagrams  that 
some  of  them  have  the  same  boundary  data  element  but 
with  different  icom  relation  in  contrast  with  their  parent. 
Then  it  is  am.  icom  ERROR. 


(defrule  check-Schild-icom 
(declare  (salience  -5)) 

(paorentS-boundary  ?p-name  ?p-data  ?p-rel) 

(childS-boundary  ?p-name  ?c-name  ?p-data  ?c-rel) 

(test  (neq  ?p-rel  ?c-rel)) 

=> 

(printout  t  "ERROR:  icom  inconsistency  between  activity  " 
?p-name  "  and  its  child  diagram  "  ?c-name  crlf) 
(assert  (syntax-error-occurred)) 

) 


;  This  rule  checks  if  a  parent  have  5  child,  eind  there  is  some 


C-39 


boundary  data  element  in  the  child  diagrams 

but  can’t  find  the  same  data  in  their  parent  then  inconsistency 
happened. 


(deliule  check-6child-child 
(declare  (salience  -6)) 

(childS-boundaory  Tp-name  Tc-name  ?c-data  ?c-rel) 

(not  (consists-oi-name  ?  ?p-data  Tc-data)) 

(not  (parentS-boundary  Tp-name  ?c-data  ?p-rel)) 

=> 

(printout  t  "ERROR:  Data  inconsistency  between  child  activity 
"  ?c-name  "  data  ?c~rel  "  ?C“data  "  and  its 
parent."  crll) 

(assert  (syntax-error-occurred)) 

) 


Parent  with  5  child  diagrams 


The  initial  icora  nximber  was  build  up  by  this  rule, 


(defrule  parents- i com- c 
(declare  (salience  -2)) 

( pair ent 5-boundary  ?p5-name  ?p6-data  c) 

=> 

(assert  (parentS-icom  TpS-naane  ?p5-data  control  1)) 

) 

(defrule  parentS-icom-o 
(declare  (salience  -2)) 

(parentS-boundary  ?p5-name  ?p5-data  o) 

=> 

(assert  (parentS-icom  ?p5-name  ?p5-data  output  1)) 

) 

(defrule  parentS-icora-i 
(declare  (salience  -2)) 

(parentS-boundary  ?p5-name  ?p5-data  i) 

=> 

(assert  (parentS-icom  ?p5-name  ?p5-data  input  1)) 

) 

(defrule  parentS-icom-m 
(declare  (salience  -2)) 

(parentS-boundary  ?p5-name  ?p5-data  m) 

=> 

(assert  (parentS-icom  ?p5-name  ?p6-data  mech  1)) 
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) 


(defrule  pairentS-control-add 
(declare  (salience  -3)) 

?ll<-(parent6~icom  ?p5-name  ?datal  control  ?one) 
?f2<-(parent6~icom  ?p5-naine  ?data2  control  ?n) 

(test  (neq  ?datal  ?data2)) 

=> 

(retract  ?fl  ?f2) 

(bind  ?total  (+  ?one  ?n)) 

(assert  (parent6-icora  ?p5-name  =(gensym)  control  ?total)) 

) 


(delrule  parentB-output-add 
(declare  (salience  -3)) 

?il<-(parent5-icora  ?p5-naine  ?datal  output  ?one) 
?12<-(parent6“-icom  ?p5-name  ?data2  output  ?n) 

(test  (neq  ?datal  ?data2)) 

=> 

(retract  ?fl  ?f2) 

(bind  ?total  (+  ?one  ?n)) 

(assert  (parentB-icom  TpB-name  -(gensyra)  output  ?total)) 

) 


(defrule  parentB-input-add 
(declare  (salience  -3)) 

?fl<- (parent B-icom  ?pB“narae  ?datal  input  ?one) 
?f2<“(parentB-icom  ?pB-naine  ?data2  input  ?n) 

(test  (neq  ?datal  ?data2)) 

=> 

(retract  ?fl  ?f2) 

(bind  ?total  (+  ?one  ?n)) 

(assert  (parentB-icom  ?p6-name  =(gensym)  input  ?total)) 

) 


(defrule  parentB-mech-add 
(declare  (salience  -3)) 

?f  l<-(parentB--icora  ?p6-naine  ?datal  mech  Tone) 
?f2<-(parentS-icom  TpB-name  ?data2  mech  ?n) 
(test  (neq  Tdatal  ?data2)) 

=> 

(retract  ?fl  ?f2) 

(bind  Ttotal  (+  Tone  Tn)) 
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(assert  (parentS-icora  ?p5-name  =(gensyro)  mech  ?total)) 

) 


(delrulo  childS-icom-c 
(declare  (salience  ~2)) 

(childS^boundeory  ?c6-parent  ?p6-name  ?c6-data  c) 

=> 

(assert  (childS-icom  ?c5-parent  ?cS“data  control  1)) 

) 

(defrule  child6-icom-o 
(declare  (salience  ~2)) 

(childS-boundary  ?c5-parent  TcS-nanie  ?c5-data  o) 

=> 

(assert  (child5-icom  ?c5-parent  ?c5*“data  output  1)  ) 

) 

(delrule  child5-icom-i 
(declare  (salience  ~2)) 

(child5“boundary  ?c5-parent  ?c5“naine  ?c5“data  i) 

=> 

(assert  (childS-icom  ?c6-parent  ?c5~data  input  1)  ) 

) 

(delrule  child5-icom-m 
(declare  (salience  -2)) 

(childS-boundary  ?c5-parent  ?c5-naine  ?c5“data  m) 

=> 

(assert  (childS-icom  ?c5-parent  ?c5-data  mech  1)  ) 

) 


(defrule  child5-control-add 
(declare  (salience  -3)) 

?f l<-(child5“icom  ?c5-*parent  ?datal  control  ?one) 
?12<“(child5“icom  ?c5-parent  ?data2  control  ?n) 

(test  (neq  ?datal  ?data2)) 

=> 

(retract  ?fl  ?f2) 

(bind  ?total  (+  ?one  ?n)) 

(assert  (childS-icora  ?c5-par€nt  =(gensym)  control  ?total)) 

) 


(defrule  child6-output-add 
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(declare  (salience  ~3)) 

?ll<*(child5-*icom  ?c6-parent  ?datal  output  Tone) 
?12<-(child6-icom  ?c6-parent  ?data2  output  ?n) 

(test  (neq  Tdatal  ?data2)) 

“> 

(retract  ?fl  ?12) 

(bind  Ttotal  (+  Tone  Tn)) 

(assert  (childS-icom  Tc5~parent  =(gensyra)  output  Ttotal)) 

) 


(defrule  childS- input- add 
(declare  (salience  -3)> 

Tf l<-(child6-icom  Tc6-parent  Tdatal  input  Tone) 
T12<-(child5~icom  Tc5-parent  Tdata2  input  Tn) 

(test  (neq  Tdatal  Tdata2)) 

=> 

(retract  Til  T12) 

(bind  Ttotal  (+  Tone  Tn)) 

(assert  (childS-icom  Tc5-parent  =(gensym)  input  Ttotal)) 

) 


(delrule  childS-mech-add 
(declare  (salience  -3)) 

Til<-(childB-icoro  Tc5-parent  Tdatal  mech  Tone) 

Ti2<-(child6"icom  Tc5  -parent  Tdata2  mech  Tn) 

(test  (neq  Tdatal  Tdata2)) 

=> 

(retract  Tfl  Tf2) 

(bind  Ttotal  (+  Tone  Tn)) 

(assert  (childB-icom  TcB-parent  =(gensym)  mech  Ttotal)) 

) 

;  Check  Parent  with  B  child  boundary  icom  number  consistancy 


(defrule  check-parent-Bchild-control 
(declare  (salience  -6)) 

(parentS-icom  TpB-name  T  control  Tp) 

(childB-icom  TpB-nsane  T  control  Tc) 

(test  ( !=  Tp  Tc)) 

=> 

(if  (>  Tp  Tc) 
then 

(bind  Tpd  (-  Tp  Tc)) 

(printout  t  “WARNING,  there  might  be  an  ERROR:  The  number  of  boundary  controls"  crlf) 
(printout  t  "  of  parent  activity  "TpB-name"  is  "Tpd"  control (s)  more  than  "  crlf) 

(printout  t  "  its  child  activities."  crlf) 
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^printout  t  '*  Are  there  * ‘consists  data  items  at  boundary?"  crll) 

(printout  t  "  Please  recheck  the  syntax."  crlf) 
else 

(bind  ?cd  (-  ?c  ?p)) 

(printout  t  "WARNING,  there  might  be  an  ERROR:  The  number  oi  boundary  controls"  crlf) 
(printout  t  "  of  the  parent  activity  "?p5-name"  is  "?cd"  control(s)  less  "  crlf) 
(printout  t  "  than  its  child  boundary  controls."  crlf) 

(printout  t  "  Are  there  “consists  of“  data  items  at  boundary?"  crlf) 

(printout  t  "  Please  recheck  the  syntax."  crlf) 


(defrule  check-parent“5child-output 
(declare  (salience  -6)) 

(parent5“icom  ?p5“name  ?  output  ?p) 

(childS-icora  ?p5-name  ?  output  ?c) 

(test  ( !=  ?p  ?c)) 

=> 

(if  (>  ?p  ?c) 
then 

(bind  ?pd  (-  ?p  ?c)) 

(printout  t  "WARNING,  there  might  be  an  ERROR:  The  niimber  of  boundeory  outputs"  crlf) 
(printout  t  "  of  parent  activity  "  ?p5-name  "  is  "  ?pd  "  output (s)  more  "  crlf) 
(printout  t  "  than  its  child  activities."  crlf) 

(printout  t  "  Are  there  “consists  of''  data  items  at  boundary?"  crlf) 

(printout  t  "  Please  recheck  the  syntax."  crlf) 
else 

(bind  ?cd  (-  ?c  ?p)) 

(printout  t  "WARNING,  there  might  be  an  ERROR:  The  number  of  boundary  outputs"  crlf) 
(printout  t  "  of  the  parent  activity  "  ?p5"name  "  is  "  ?cd  "  output (s)  less  "  crlf) 
(printout  t  "  than  its  child  boundary  outputs."  crlf) 

(printout  t  "  Are  there  “consists  of''  data  items  at  boundary?"  crlf) 

(printout  t  "  Please  recheck  the  syntax."  crlf) 


(defrule  check-par ent-Schild-input 
(declare  (salience  -6)) 
(parent5“icom  ?p5-name  ?  input  ?p) 
(childS-icom  ?pb-name  ?  input  ?c) 
(test  (!=  ?p  ?c)) 

=> 


(if  (>  ?p  ?c) 
then 

(bind  ?pd  (-  ?p  ?c)) 

(printout  t  "WARNING,  there  might  be  an  ERROR:  The  number  of  boundary  inputs"  crlf) 
(printout  t  "  of  parent  activity  "  ?p5-name  "  is  "  ?pd  "  input(s)  more  "  crlf) 
(printout  t  "  than  its  child  activities."  crlf) 

(printout  t  "  Are  there  “consists  of''  data  items  at  boundary?"  crlf) 

(printout  t  "  Please  rech^ck  the  syntax."  crlf) 


else 

(bind  ?cd  (-  ?c  ?p)) 

(printout  t  "WARNING,  there  might  be  an  ERROR:  The  number  of  boundary  inputs"  crlf) 
(printout  t  "  of  the  parent  activity  "  ?p5-naine  "  is  "  ?cd  "  input (s)  less  "  crlf) 
(printout  t  "  than  its  child  boundaory  inputs."  crlf) 

(printout  t  "  Are  there  ''consists  of*'  data  items  at  boundary?"  crlf) 

(printout  t  "  Please  recheck  the  syntax."  crlf) 

)  ) 


(defrule  check-parent-Schild-mech 
(declare  (salience  -6)) 

(parent5*“icom  ?p5-name  ?  mech  ?p) 

(childB-icom  TpB-name  ?  mech  ?c) 

(test  ( !=  ?p  ?c)) 

=> 

(if  (>  ?p  ?c) 
then 

(bind  ?pd  (-  ?p  ?c)) 

(printout  t  "WARNING,  there  might  be  an  ERROR:  The  number  of  boundary  mechanisms"  crlf) 
(printout  t  "  of  parent  activity  "  TpB-name  "  is  "  ?pd  "  mechanism(s)  more  "  crlf) 
(printout  t  "  than  its  child  activities."  crlf) 

(printout  t  "  Are  there  ''consists  of**  data  items  at  boundary?"  crlf) 

(printout  t  '*  Please  recheck  the  syntax."  crlf) 
else 

(bind  ?cd  (-  ?c  ?p)) 

(printout  t  ‘‘WARNING,  there  might  be  an  ERROR:  The  number  of  boundary  mechanisms"  crlf) 
(printout  t  "  of  the  parent  activity  "  TpB-name  "  is  "  Ted  "  mechnaism(s)  less  "  crlf) 
(printout  t  "  its  child  child  boundary  mechanisms."  crlf) 

(printout  t  "  Are  there  ''consists  of**  data  items  at  boundary?"  crlf) 

(printout  t  "  Please  recheck  the  syntax."  crlf) 

)  ) 


;  This  rule  will  create  the  boundary  facts  for  activities  having 
;  6  child  diagrams. 

(defrule  parent-Bchild 
(declare  (salience  100)) 

?f l<-(act-has-child  TparentO  Tchildlft^null) 

?f2<-(act-has-child  TparentB  ?child2&‘’?childl&'’null) 
?f3<-(act-has-child  TparentB  ?child3&''?child2&“?childi&“null) 
?f4<-(act-has-child  TparentB 

?child4&''?child3&'"?child2&*?childl&''null) 
?fS<-(act-has-child  TparentS 

?child5&''?child4&“?child3&''?child2&''?childl&''null) 
?f 6<-(act-has-child  TparentB 
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?child6&'*?child5&‘'?child4&''?child3fc''?child2&''?childl&-null) 

(not  (act-has-child  ?parent6 

?child7&'?child6&''?child5&“?child4&''?child3&''?child2&"-'childl&''null)  ) 


=> 

(retract  ?fl  ?f2  ?f3  ?f4  ?f5  ?f6) 

(assert  (parents  ?parent6  ?childl  ?child2  ?child3  ?child4 

?child5  ?child6)) 


) 


(defrule  parent 6-boundary 

(parents  ?parentS  ?childl  ?child2  ?child3  ?child4  ?child5  TchildS) 
(icom-tuple  ?parent6  ?p-data  ?p-rel  ?) 

=> 

(assert  (parentS-boundary  ?parentS  ?p-data  ?p-rel)) 

) 


(defrule  childS-boundary-childl 

(parents  ?parentS  ?childl  ?child2  ?child3  ?child4  ?child5  ?child6) 
(icom-tuple  ?childl  ?cl-data  ?cl-rel  ?) 

=> 

(assert  (childS-boundary  ?parentS  ?childl  ?cl-data  ?cl-rel)) 

) 


(defrule  child6-boundary-child2 

(parents  ?parentS  ?childl  ?child2  ?child3  ?child4  ?child5  TchildS) 
(icom-tuple  ?child2  ?c2-data  ?c2-rel  ?) 

=> 

(assert  (childS-boundary  ?parentS  ?child2  ?c2-data  ?c2-rel)) 

) 


(defrule  child6-boundary-child3 

(parents  TparentS  ?childl  ?child2  ?child3  ?child4  ?child5  ?child6) 
(icom-tuple  ?child3  ?c3-data  ?c3-rel  ?) 

=> 

(assert  (childS-boundary  TparentS  ?child3  ?c3-data  ?c3-rel)) 

) 


(defrule  child6-boundary-child4 

(parents  ?parent6  ?childl  ?child2  ?child3  ?child4  ?child5  ?child6) 
(icom-tuple  ?child4  ?c4-data  ?c4-rel  ?) 

=> 

(assert  (childS-boundary  ?parent6  ?child4  ?c4-data  ?c4-rel)) 

) 

(defrule  childS-boundary-childS 

(parents  ?parentS  ‘^childl  ?child2  ?child3  ?child4  ?child5  ?childS) 
(icom-tuple  ?child5  ?c5-data  ?c5-rel  ?) 

=> 


(assert  (childS-boundary  ?parent6  ?child5  “^cS-data  ?c5-rel)) 


) 


(delrule  childS-boundary-childS 

(parents  ?parent6  ?childl  ?child2  ?child3  ?child4  ?child5  ?child6) 
(icom-tuple  ?child6  ?c6-data  ?c6-rel  ?) 

=> 

(assert  (childS-boundary  ?parent6  ?child6  ?c6-data  ?c6-rel)) 

) 


These  rules  will  clear  the  duplicated  boundary  facts  in  the  facts 
created  by  the  previous  rule. 

CONDITION: 

1.  5  activities  out  of  6  sharing  a  same  data 

2.  4  activities  out  of  6  sharing  a  same  data 

3.  3  activities  out  of  6  sharing  a  same  data 

4.  2  activities  out  of  6  sharing  a  same  data 

5.  all  6  activities  are  sharing  a  same  data 
element  but  with  different  icom  code 

Condition  1  and  5  is  not  likely  to  happen »  so  it  is  not  implemented 


(defrule  clear-6child-4mid 

?f l<-(child6-boundary  ?parent6  ?childl  ?cl-data  ?cl-rel) 

?f2<-(child6-boundary  ?parent6  ?child2&''?childl  ?cl-data  ?c2-rel&''?cl-rel) 
?f3<“(child6“boundary  ?parent6  ?child3&"?child2&'’?childl  ?cl-data 

?c3-rel&‘'?c2“rel&''?cl-rel) 

?f4<-(child6-'boundary  ?parent6  ?child4&’'?child3&''?child2&''?childl  ?cl-data  ?c4-j.>il) 
(test  (or  (and  (neq  ?c4-rel  ?cl-rel) 

(neq  ?c4-rel  ?c2“rel) 

(eq  ?c4-rel  ?c3-rel)  ) 

(and  (eq  ?c4“rel  ?cl~rel) 

(neq  ?c4-rel  ?c2-rel) 

(neq  ?c4-rel  ?c3“rel)  ) 

(and  (neq  ?c4-rel  ?cl“rel) 

(eq  ?c4-rel  ?c2-rel) 

(neq  ?c4-rel  ?c3-rel)  )  )) 

=> 

(retract  ?fl) 

(retract  ?f2) 

(retract  ?f3) 

(retract  ?f4) 

) 


(defrule  clear-Schild-Smid 

?f l<-(child6“boundary  ?parent6  ?childl  ?cl“data  ?cl-rel) 
?f2<-(child6-boundary  ?parent6  ?child2&''?childl  ?cl-data  ?c2-rel&‘’?cl~rel) 
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?13<-(child6“boundary  ?pairent6  ?child3ft''?child2&"'?childl  ?cl“data 

?c3-rel&''?c2-rel&''?cl-rel) 

=> 

(retract  ?jfl) 

(retract  ?f2) 

(retract  ?f3) 

) 


;  II  a  intermediate  arrow  is  the  input  ol  one  box  but  also  the 
;  output  and  input  of  another  two  boxes.  It  must  be  removed  before 
;  the  arrow  between  the  other  boxes  been  removed. 


(defrule  clear“6child“2mid“l 

(child6-boundary  ?parent6  ?childl  ?cl-data  ?cl-rel) 

(child6-boundary  ?parent6  ?child2&‘'?childl  ?cl-data  ?c2“rel&''?cl“rel) 

?fl<-  (childS-boundary  ?parent6  ?child3&'‘?child2&'’?childl  ?cl“*data  ?c3-rel) 
(test  (or  (eq  ?c3-rel  ?c2“rel) 

(eq  ?c3-rel  ?cl-rel))  ) 

=> 

(retract  ?fl) 

) 


(defrule  clear-6child-2mid 
(declare  (salience  -1)) 

?f l<~(child6-boundary  ?parent6  ?childi  ?cl-data  ?cl“rel) 
?f2<-(child6“boundary  ?parent6  ?child2&''?childl  ?cl-data  ?c2-rel&''?cl-rel) 
=> 

(retract  ?fl) 

(retract  ?f2) 

) 


(defrule  remove“6child-4boundary 

(child6-boundary  ?parent6  ?childl  ?cl~data  Tcl-rel) 

?f2<“  (childG-boundary  ?parent6  ?child2&''?childl  ?cl“data  ?cl-rel) 

?f3<~  (child6“boundary  ?parent6  ?child3&*'?child2&‘'?childl  ?cl-data  ?cl“rel) 

?f4<~  (child6-boundary  ?parent6  ?child4&'’?child3&‘'?chiid2&''?childl  ?cl-data  ?cl-“rel) 
=> 

(retract  ?f2  ?f3  ?f4) 

) 


(defrule  remove-6child“3boundary 

(childe-boundary  ?parent6  ?childl  ?cl-data  ?cl-rel) 

?f2<-  (child6“boundary  ?parent6  ?child2&"?childl  ?cl-data  ?cl-rel) 


?13<-  (child6“boundary  ?parent6  ?child3&"?child2&"?childl  ?cl-data  Tcl-rel) 
=> 

(retract  ?12  ?f3) 

) 


(defrule  remove-6child--2boimdary 

(child6“boundary  ?pareiit6  ?childl  ?cl~data  ?cl--rel) 
?f2<-(child6“boundary  ?parent6  ?child2&''?childl  ?cl-data  ?cl-rel) 
=> 

(retract  ?f2) 

) 


(defrule  rid-6child-3consists 

?f  l<-(child6-bouiidary  Tpairente  ?childl  ?cl-data  ?cl-rel) 

?f2<“(child6-boundary  ?parent6  ?child2&''?childl  ?c2-data&'’?cl-data  ?c2“rel) 
?f3<-(child6“boundary  ?pareiit6  ?child3&''?child2&"?childl 

?c3~d:ta&"?c2-data&"'?cl-data  ?c3-rel) 
?f4<-’(child6”boundary  ?parent6  ?child~p&‘'?child3&''?child2&''?childl 

?cp-data&‘'?c3-data&‘'?c2-data&"?cl-data  ?cp“rel&"?c3-rel&''?c2-rel&''?cl-rel) 
( cons ists“0f -name  ?  ?cp-data  ?c3“data) 

(consists-of-narae  ?  ?cp-data  ?c2-data) 

(cons ists-of -name  ?  ?cp-data  ?c 1-data) 

=> 

(retract  ?fl) 

(retract  ?f2) 

(retract  ?f3) 

(retract  ?f4) 

) 


(defrule  rid-6child-2consists 
(declare  (salience  -1)) 

?f l<-(child6-boundary  ?parent6  ?childl  ?cl-data  ?cl-rel) 

?f2<-(child6-boundary  ?parent6  ?child2&''?childl  ?c2-data&‘'?cl-data  ?c2-rel) 
?f3<-(child6-boundary  ?parent6  ?child-p&‘'?child2&''?childl 

Tcp-datafe" ? c2-dat aft" ?cl -data  ?cp-rel&''?c2-rel&''?cl-rel) 
(consists-of-name  ?  ?cp-data  ?c2-data) 

(consists-of-name  ?  ?cp-data  ?cl-data) 

=> 

(retract  ?fl  '?f2  ?f3) 

) 


This  rule  check  a  parent  activity  with  6  child  diagram  to  see  if 
there  are  any  boundary  data  belonging  to  the  parent  but  not  a  part  of 
the  child  diagrams. 
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(defrule  check-6child~parent 
(declare  (salience  ~5)) 

(parent 6-boundary  ?p-naine  ?p-data  ?p-rel) 

(not  (consists-of-name  ?  ?p-data  ?c-data)) 

(not  (child6-boundary  ?p-name  ?child6  ?p-data  ?c6-rel)) 

=> 

(printout  t  “ERROR:  Data  inconsistency  between  parent  activity 
"?p-naine  “  data  ?p-rel  “  ?p-data  “  and  its  child 
diagrams.**  crlf) 

(assert  (syntax-error-occurred)) 

) 

(defrule  check-6child-parent-cons ists 
(declare  (salience  -6)) 

(parentS-boundary  ?p-name  ?p-data  ?p-rel) 

(consists-of-name  ?  ?p-data  ?c-data) 

(not  (child6-boundary  ?p-naroe  ?child6  ?c-data  ?c6-rel)) 

=> 

(printout  t  “ERROR:  Data  inconsistency  between  parent  activity 
**?p-name  “  data  ?p-rel  “  ?p-data  “  and  its  child 
diagrams.'*  crlf) 

(assert  (syntax-error-occurred)) 

) 


This  rule  checks  if  a  parent  with  6  child  diagrams  that 
some  of  them  have  the  same  boundary  data  element  but 
with  different  icora  relation  in  contrast  with  their  parent. 
Then  it  is  an  icom  ERROR. 


(defrule  check-6child-icom 
(declare  (salience  -5)) 

(parent6-boundary  ?p-name  ?p-data  ?p-rel) 

(childC-boundary  ?p-name  ?c-name  ?p-data  ?c-rel) 

(test  (neq  ?p-rel  ?c-rel)) 

=> 

(printout  t  “ERROR:  icom  inconsistency  between  activity  “ 
?p-name  "  and  its  child  diagram  “ 

?c-name  “.**  crlf) 

(assert  (syntax-error-occurred)) 

) 


This  rule  checks  if  a  parent  have  6  child,  and  there  is  some 
boundary  data  element  in  the  child  diagrams 

but  can't  find  the  same  data  in  their  parent,  then  inconsistency 
happened. 
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(defrule  check-Bchild-child 
(declare  (salience  “5)) 

(childS-bonndary  ?p-name  ?c-naxne  ?c-data  Tc-rel) 

(not  (consists-oi-name  ?  ?p~data  ?c~data)) 

(not  (parent 6-boundary  ?p-name  ?c-data  ?p-rel)) 

=> 

(printout  t  "ERROR:  Data  inconsistency  between  child  activity 
"  ?c-naine  "  data  *"  ?c-rel  "  ?c-data  "  and  its 
parent."  crlf) 

(assert  (syntax-error-occurred)) 

) 


Parent  with  6  child  diagrams 


The  initial  icom  number  was  build  up  by  this  rule, 


(defnile  parent6-icom-c 
(declare  (salience  -2)) 

(parent6-boundary  ?p6-name  ?p6-data  c) 

=> 

(assert  (parentS-icom  ?p6-name  ?p6-data  control  1)) 

) 

(defrule  parents- icom-o 
(declare  (salience  -2)) 

(parentG-boundary  ?p6“name  ?p6-data  o) 

=> 

(assert  (parentS-icom  ?p6-name  ?p6-data  output  1)) 

) 

(defrule  parent 6- i com- i 
(declare  (salience  -2)) 

(parent6-boundciry  ?p6  -name  ?p6-data  i) 

=> 

(assert  (parent6-icom  ?p6-name  ?p6-data  input  1)) 

) 

(defrule  parent6-icom-m 
(declare  (salience  -2)) 

(parent 6-boundary  ?p6-name  ?p6-data  m) 

=> 

(assert  (parent6-icom  ?p6-name  ?p6-data  mech  1)) 

) 
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(defrule  parent6“Control-add 
(declare  (salience  -3)) 

?ll<-(parent6-icom  TpB-naine  ?datal  control  Tone) 
?f2<-(parent6“icom  ?p6-name  ?data2  control  ?n) 

(test  (neq  Tdatal  ?data2)) 

=> 

(retract  ?11  ?12) 

(bind  Ttotal  (+  Tone  Tn)) 

(assert  (parent6-icora  Tp6-name  =(gensym)  control  Ttotal)) 

) 


(defrule  parentC-output-add 
(declare  (salience  ~3)) 

Tf l<-(parent6“icom  Tp6-name  Tdatal  output  Tone) 
Tf2<-(parent6-icom  Tp6-narae  Tdata2  output  Tn) 

(test  (neq  Tdatal  Tdata2)) 

=> 

(retract  Tfl  Tf2) 

(bind  Ttotal  (+  Tone  Tn)) 

(assert  (parent6-icora  TpB-name  =(gensym)  output  Ttotal)) 

) 


(defrule  parent6“input-add 
(declare  (salience  -3)) 

Tf  l<-*(  par  enteric  om  Tp6~naine  Tdatal  input  Tone) 
Tf2<-(parent6~icom  Tp6-name  Tdata2  input  Tn) 

(test  (neq  Tdatal  Tdata2)) 

=> 

(retract  Tfl  Tf2) 

(bind  Ttotal  (+  Tone  Tn)) 

(assert  (parent6-icom  Tp6-nanie  =(gensyra)  input  Ttotal)) 

) 


(defrule  parentB-mech-add 
(declare  (salience  ~3)) 

Tf l<-(parent6“icom  TpG-name  Tdatal  mech  Tone) 
Tf2<-(parent6“icom  TpG-name  Tdata2  mech  ?n) 

(test  (neq  Tdatal  ?data2)) 

=> 

(retract  Tfl  Tf2) 

(bind  Ttotal  (+  Tone  Tn)) 

(assert  (parentS-icom  Tp6-name  =(gensyra)  mech  Ttotal)) 

) 
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(defrule  childS-icom-c 
(declare  (salience  -2)) 

(child6“boundary  ?c6“parent  ?c6-naine  ?c6“data  c) 

=> 

(assert  (child6-icora  ?c6~parent  ?c6~data  control  l)) 

) 

(defrule  child6-icom-o 
(declare  (salience  -2)) 

(child6“boundary  ?c6-parent  ?c6“name  ?c6“data  o) 

=> 

(assert  (child6-iconi  ?c6"parent  ?c6-data  output  1)  ) 

) 

(defrule  child6-icom-i 
(declare  (salience  -2)) 

(childS-boundary  ?c6“parent  TcS-name  ?c6-data  i) 

=> 

(assert  (child6-icom  ?c6“parent  ?c6“data  input  1)  ) 

) 

(defrule  child6-*icoin-m 
(declare  (salience  -2)) 

(child6-boundary  ?c6“parent  TcC-naine  ?c6-data  m) 

=> 

(assert  (child6-icom  ?c6-parent  ?c6~data  inech  1)  ) 

) 


(defrule  childS-control-add 
(declare  (salience  -3)) 

?f l<-(child6-icom  ?c6-parent  ?datal  control  ?one) 
?f2<~(child6“icom  ?c6-parent  ?data2  control  ?n) 

(test  (neq  ?datal  ?data2)) 

=> 

(retract  ?fl  ?f2) 

(bind  ?total  (+  Tone  ?n)) 

(assert  (child6-icora  ?c6“parent  =(gensym)  control  Ttotal)) 

) 


(defrule  childS-output-add 
(declare  (salience  -3)) 

?f l<-(child6-icom  ?c6-parent  Tdatal  output  ?one) 
?f2<~(child6-icom  ?c6-*parent  ?data2  output  ?n) 
(test  (neq  Tdatal  ?data2)) 
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=> 

(retract  ?il  ?i2) 

(bind  ?total  (+  Tone  ?n)) 

(assert  (child6-iconi  ?c6“parent  =(gensym)  output  Ttotal)) 

) 


(delrule  childe-input-add 
(declare  (salience  -3)) 

?ll<-(child6-icom  ?c6-p2a:ent  Tdatal  input  Tone) 
T12<-(child6“icoin  TcC-pairent  Tdata2  input  Tn) 

(test  (neq  Tdatal  Tdata2)) 

=> 

(retract  Til  Ti2) 

(bind  Ttotal  (+  Tone  Tn)) 

(assert  (child6-icora  Tc6“parent  =(gensyra)  input  Ttotal)) 

) 


(defrule  childS-mech-add 
(declare  (salience  -3)) 

Tf l<~(child6-icora  Tc6“parent  Tdatal  mech  Tone) 
T12<-*(child6-icom  Tc6-*parent  Tdata2  mech  Tn) 

(test  (neq  Tdatal  Tdata2)) 

=> 

(retract  Til  Tf2) 

(bind  Ttotal  (+  Tone  Tn)) 

(assert  (child6-icora  Tc6-parent  =(gensyin)  mech  Ttotal)) 

) 


;  Check  Parent  with  6  child  boundary  icom  number  consistancy 


(defrule  check-pai ent“6child~control 
(declare  (salience  -6)) 

(parent6-icom  Tp6-name  T  control  Tp) 

(child6"icom  TpS-name  T  control  Tc) 

(test  (!=  Tp  Tc)) 

=> 

(if  (>  Tp  Tc) 
then 

(bind  Tpd  (-  Tp  Tc)) 

(printout  t  "WARNING,  there  might  be  an  ERROR:  The  number  of  boundary  controls"  crlf) 
(printout  t  **  of  parent  activity  "TpG-name"  is  '*?pd"  control (s)  more  than  "  crlf) 

(printout  t  "  its  child  activities."  crlf) 

(printout  t  "  Are  there  * ‘consists  of*'  data  items  at  boundaryT"  crlf) 
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(printout  t  **  Please  recheck  the  syntax.*'  crll) 
else 

(bind  ?cd  (-  ?c  ?p)) 

(printout  t  "WARNING,  there  might  be  am  ERROR:  The  number  oi  boundary  controls"  crlf) 
(printout  t  "  ot  the  parent  activity  "?p6“name"  is  "?cd"  control(s)  less  "  crlf) 
(printout  t  "  than  its  child  boundary  controls."  crlf) 

(printout  t  "  Are  there  “consists  of“  data  items  at  boundary?"  crlf) 

(printout  t  "  Please  recheck  the  syntax."  crlf) 

)  ) 

(delrule  check“parent-*6child--output 
(declare  (salience  -6)) 

(parent6“icom  ?p6-name  ?  output  ?p) 

(child6-icom  TpS-name  ?  output  ?c) 

(test  (!=  ?p  ?c)) 

=> 

(if  (>  ?p  ?c) 
then 

(bind  ?pd  (-  ?p  ?c)) 

(printout  t  "WARNING,  there  might  be  an  ERROR:  The  number  of  boundary  outputs"  crlf) 
(printout  t  "  of  parent  activity  "  ?p6-*naroe  "  is  "  ?pd  "  output(s)  more  "  crlf) 
(printout  t  "  than  its  child  activities."  crlf) 

(printout  t  "  Are  there  “consists  of“  data  items  at  boundary?"  crlf) 

(printout  t  "  Please  recheck  the  syntax."  crlf) 
else 

(bind  ?cd  (-  ?c  ?p)) 

(printout  t  "WARNING,  there  might  be  an  ERROR:  The  number  of  boundary  outputs"  crlf) 
(printout  t  "  of  the  parent  activity  "  ?p6-narae  "  is  "  ?cd  "  output (s)  less  "  crlf) 
(printout  t  "  than  its  child  boundary  outputs."  crlf) 

(printout  t  "  Are  there  “consists  of“  data  items  at  boundary?"  crlf) 

(printout  t  "  Please  recheck  the  syntax."  crlf) 


(defrule  check-par ent-Cchild- input 
(declare  (salience  -6)) 

(parent6-icom  ?p6-name  ?  input  ?p) 

(child6-icom  ?p6-name  ?  input  ?c) 

(test  ( !=  ?p  ?c) ) 

=> 

(if  (>  ?p  ?c) 
then 

(bind  ?pd  (-  ?p  ?c)) 

(printout  t  "WARNING,  there  might  be  an  ERROR:  The  number  of  boundary  inputs"  crlf) 
(printout  t  "  of  parent  activity  ?p6-name  "  is  "  ?pd  "  input (s)  more  "  crlf) 
(printout  t  "  than  its  child  activities."  crlf) 

(printout  t  "  Are  there  “consists  of“  data  items  at  boundary?"  crlf) 

(printout  t  "  Please  recheck  the  syntax."  crlf) 
else 

(bind  ?cd  (-  ?c  ?p)) 

(printout  t  "WARNING,  there  might  be  an  ERROR:  The  number  of  boundary  inputs"  crlf) 
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(printout  t  '*  of  the  parent  activity  ?p6-riaine  '*  is  "  ?cd  "  input(s)  less  '*  crlf) 
(printout  t  "  than  its  child  boundary  inputs."  crlf) 

(printout  t  "  Are  there  * ‘consists  of’*  data  items  at  boundary?"  crlf) 

(printout  t  "  Please  recheck  the  syntax."  crlf) 


(defrule  check-parent-dchild-mech 
(declare  (salience  -6)) 

(parent6-icom  ?p6-name  ?  mech  ?p) 

(child6-icom  ?p6-naiae  ?  roech  ?c) 

(test  (1=  ?p  ?c)) 

=> 

(if  (>  ?p  ?c) 
then 

(bind  ?pd  (-  ?p  ?c)) 

(printout  t  "WARNING,  there  might  be  an  ERROR:  The  number  of  boundary  mecheinisms"  crlf) 
(printout  t  "  of  paorent  activity  "  ?p6-name  "  is  "  ?pd  "  mechanism(s)  more  "  crlf) 
(printout  t  **  than  its  child  activities."  crlf) 

(printout  t  '*  Are  there  “consists  of”  data  items  at  boundary?"  crlf) 

(printout  t  "  Please  recheck  the  syntax."  crlf) 
else 

(bind  ?cd  (-  ?c  ?p)) 

(printout  t  "WARNING,  there  might  be  an  ERROR:  The  number  of  boundary  mechanisms"  crlf) 
(printout  t  "  of  the  parent  activity  "  ?p6“n2Lme  "  is  "  ?cd  "  mechnaism(s)  less  "  crlf) 
(printout  t  "  its  child  child  boundary  mechanisms."  crlf) 

(printout  t  "  Are  there  “consists  of”  data  items  at  boundary?"  crlf) 

(printout  t  "  Please  recheck  the  syntax."  crlf) 


; ;  Auxiliary  Rules  for  checking  any  parent  activity  that  have  more  than 

;;  six  child  activities  up  to  3  levels  of  hierarchy. 

(defrule  create-A7 

(declaore  (salience  5)) 

(act-numb  ?acta7  A7) 

=> 

(assert  (act  ?acta7  7)) 


(defrule  create-A17 
(declare  (salience  5)) 
(act-numb  ?actal7  A17) 

=> 

(assert  (act  ‘?actal7  17)) 

) 


(defrule  create-A27 


(declare  (salience  5)) 
(act^numb  ?acta27  A27) 

=> 

(assert  (act  ?acta27  27)) 

) 

(delrule  create-A37 
(declare  (salience  5)) 
(act-nxunb  ?acta37  A  37) 

=> 

(assert  (act  ?acta37  37)) 

) 

(delrule  create-A47 
(declare  (salience  5)) 
(act-numb  ?acta47  A47) 

=> 

(assert  (act  ?acta47  47)) 

) 

(delrule  create-A57 
(declare  (salience  6)) 
(act-numb  ?acta67  A57) 

=> 

(assert  (act  ?acta57  57)) 

) 

(defrule  create-A67 
(declare  (salience  5)) 
(act-numb  ?acta67  A67) 

=> 

(assert  (act  ?acta67  67)) 

) 

(defrule  create“A117 
(declare  (salience  5)) 
(act-numb  ?actall7  A117) 

=> 

(assert  (act  ?actall7  117)) 

) 

(defrule  create-A127 
(declare  (salience  5)) 
(act-numb  ?actal27  A127) 

=> 

(assert  (act  ?actal27  127)) 

) 

(defrule  create-A137 
(declare  (salience  5)) 
(act-numb  ?actal37  A137) 
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(assert  (act  ?actal37  137)) 

) 

(delrule  create~A147 
(declare  (salience  5)) 
(act-nxunb  ?actai47  A147  ) 

=> 

(assert  (act  ?actal47  147)) 

) 

(defrule  create-A157 
(declare  (salience  6)) 
(act-numb  ?actal57  A157) 

=> 

(assert  (act  ?actal67  167)) 

) 

(defrule  create-A167 
(declare  (salience  5)) 
(act-numb  ? act a 167  A 167) 

=> 

(assert  (act  ?actal67  167)) 

) 

(defrule  create-A217 
(declare  (salience  5)) 
(act-numb  ?acta217  A217) 

=> 

(assert  (act  ?acta217  217)) 

) 

(defrule  create-A227 
(declare  (salience  .)) 
(act-numb  ?acta227  A227) 

=> 

(assert  (act  ?acta227  227)) 

) 

(defrule  create-A237 
(declare  (salience  5)) 
(act-numb  ?acta237  A237) 

=> 

(assert  (act  ?acta237  237)) 

) 

(defrule  create-A247 
(declare  (salience  5)) 
(act-numb  ?acta247  A247) 

=> 

(assert  (act  ?acta247  247)) 

) 


(defrule  create-A257 
(declare  (salience  5)) 
(act-numb  ?acta257  A257) 

=> 

(assert  (act  ?acta257  257)) 

) 

(defrule  create-A267 
(declare  (salience  5)) 
(act-numb  ?acta267  A267) 

=> 

(assert  (act  ?acta267  267)) 

) 

(defrule  create-A317 
(declare  (salience  5)) 
(act-numb  ?acta317  A317) 

=> 

(assert  (act  ?acta317  317)) 

) 

(defrule  create-A327 
(declare  (salience  5)) 
(act-numb  ?acta327  A327) 

=> 

(assert  (act  ?acta327  327)) 

) 

(defrule  create-A337 
(declare  (salience  5)) 
(act-numb  ?acta337  A337) 

=> 

(assert  (act  ?acta337  337)) 

) 

(defrule  create-A347 
(declare  (salience  5)) 
(act-numb  ?acta347  A347) 

=> 

(assert  (act  ?acta347  347)) 

) 

(defrule  create-A367 
(declare  (salience  6)) 
(act-numb  ?acta357  A357) 

=> 

(assert  (act  ?acta357  357)) 

) 

(defrule  create-A367 
(declare  (salience  5)) 
(act-numb  ?acta367  A367) 


=> 

(assert  (act  ?acta367  367)) 

) 

(defrule  create-A417 
(declare  (salience  5)) 
(act-numb  ?acta417  A417) 

=> 

(assert  (act  ?acta417  417)) 

) 

(defrule  create-A427 
(declare  (salience  5)) 
(act-n\imb  ?acta427  A427) 

=> 

(assert  (act  ?acta427  427)) 

) 

(defrule  create-A437 
(declare  (salience  5)) 
(act-nurob  ?acta437  A437) 

=> 

(assert  (act  ?acta437  437)) 

) 

(defrule  create-A447 
(declare  (salience  5)) 
(act-numb  ?acta447  A447) 

=> 

(assert  (act  ?acta447  447)) 

) 

(defrule  create-A457 
(declare  (salience  5)) 
(act-numb  ?acta457  A457) 

=> 

(assert  (act  ?acta457  457)) 

) 

(defrule  create-A467 
(declare  (salience  5)) 
(act-nurob  ?acta467  A467) 

=> 

(assert  (act  ?acta467  467)) 

) 

(defrule  create-A517 
(declare  (salience  5)) 
(act-numb  ?acta517  A517) 

=> 

(assert  (act  ?acta517  517)) 

) 
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(defrule  create-A527 
(declare  (salience  5)) 
(act-numb  ?acta527  A527) 

=> 

(assert  (act  ?acta527  527)) 

) 

(defrule  create-A637 
(declare  (salience  5)) 
(act-numb  ?acta537  A537) 

=> 

(assert  (act  ?acta537  537)) 


(defrule  create-A547 
(declare  (salience  5)) 
(act-numb  ?acta547  A547) 

=> 

(assert  (act  ?acta547  547)) 


(defrule  create-A557 
(declare  (salience  5)) 
(act-numb  ?acta557  A557) 

=> 

(assert  (act  ?acta567  557)) 


(defrule  create-A567 
(declare  (salience  5)) 
(act-numb  ?acta567  A567) 

=> 

(assert  (act  ?acta567  567)) 

) 

(defrule  create-A617 
(decl2Lre  (salience  5)) 
(act-numb  ?acta617  A617) 

=> 

(assert  (act  ?acta617  617)) 

) 

(defrule  create-A627 
(declare  (salience  5)) 
(act-numb  ?acta627  A627) 

=> 

(assert  (act  ?acta627  627)) 

) 

(defrule  create-A637 
(declare  (salience  5)) 
(act-numb  ?acta637  A637) 
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=> 

(assert  (act  ?acta637  637)) 

) 

(delrule  create-A647 
(declare  (salience  5)) 
(act-numb  ?acta647  A647) 

=> 

(assert  (act  ?acta647  647)) 

) 

(delrule  create-A657 
(declaire  (salience  5)) 
(act-numb  ?acta657  A657) 

C  sert  (act  ?acta657  657)) 

) 

(defrule  create-A667 
(declare  (salience  5)) 
(act-numb  ?acta667  A667) 

=> 

(assert  (act  ?acta667  667)) 

) 


END  OF  SAtool  II  RULE  BASE 
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Appendix  D.  SAMPLE  ESSENTIAL  MODEL  IDEFo  SYNTAX  CHECKING 

SCRIPT  FILE 


NOTICE:  Any  comments  added  by  the  author  will  be  followed  by  a  ‘;\ 


csh>  a. out 

CLIPS/Ada  Version  4.30  10/12/89 

♦  THE  ESSENTIAL  SUBSYSTEM  ♦ 

♦  TEST  AND  DEMONSTRATION  MAIN  MENU  ♦ 

♦  —  SAtool  II  Level  Operations  —  * 

Enter  To  select  the  desired  operation 

1.  Restore  (load)  a  project  from  disk 
(Warning:  all  current  data  cleared) 

2.  Save  the  current  project  to  disk 

3.  Display  the  current  project  name 

4.  Change  the  current  project  name 

5.  Create  and  display  a  data  dictionary  entry 

6.  Add  a  box/activity  to  the  project 

7.  Connect  2  boxes  with  a  data  element/arrow 

8.  Check  Syntax  of  current  project 

9.  —  Submenus  for  Low  Level  Operations  — 

0.  EXIT 

SELECT  A  NUMBER:  1 

Enter  the  file  name  of  the  project  to  be  restored. 

Do  not  include  the  file  name  extension. 

Enter  Name:  thesis^err 

Looking  for  essential  data  under  file  name:  thesis_err .esm 
Preparing  to  read  facts  from  disk  into  a  buffer. 

A  set  of  facts  has  been  extracted  from  the  file. 

Calling  procedure  to  load  icom  facts. 

Procedure  to  restore  ICOM  facts  done. 

A  set  of  facts  has  been  extracted  from  the  file. 

Calling  procedure  to  load  project  name  fact. 

Procedure  to  restore  project  name  is  done. 

A  set  of  facts  has  been  extracted  from  the  file. 

Calling  procedure  to  load  activity  facts. 

Procedure  to  restore  activity  facts  is  done. 

A  set  of  facts  has  been  extracted  from  the  file. 

Calling  procedure  to  load  data  element  facts. 

Procedure  to  restore  data  element  facts  is  done. 

A  set  of  facts  has  been  extracted  from  the  file. 

Calling  procedure  to  load  historical  activity  facts. 
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Procedure  to  restore  historical  activity  facts  is  done. 

A  set  of  facts  has  been  extracted  from  the  file. 

Calling  procedure  to  load  calls  relation  facts. 

Procedure  to  restore  calls  relation  facts  is  done. 

A  set  of  facts  has  been  extracted  from  the  file. 

Calling  procedure  to  load  consista  of  relation  facts. 
Procedure  to  restore  consists  of  relation  facts  is  done. 
Project  successfully  restored. 

PRESS  ANY  KEY  -  THEN  RETURN  TO  CONTINUE:  1 

*  THE  ESSENTIAL  SUBSYSTEM  ♦ 

*  TEST  AND  DEMONSTRATION  MAIN  MENU  * 

*  —  SAtool  II  Level  Operations  —  t 

Enter  To  select  the  desired  operation 

1.  Restore  (load)  a  project  from  disk 

(Warning:  all  current  data  cleared) 

2.,  Save  the  current  project  to  disk 

3.  Display  the  current  project  name 

4.  Change  the  current  project  name 

5.  Create  and  display  a  data  dictionary  entry 

6.  Add  a  box/activity  to  the  project 

7.  Connect  2  boxes  with  a  data  eleraent/arrow 

8.  Check  Syntax  of  current  project 

9.  —  Submenus  for  Low  Level  Operations  — 

0.  EXIT 

SELECT  A  NUMBER:  9 

*  ESSENTIAL  SUBSYSTEM  EDITING  AND  DEBUGGING  MENU  ♦ 

*  Warning:  These  operations  allow  you  to  directly  * 

*  exercise  the  object  operations.  Use  extreme  care.* 

*  — Essential  Model  and  Utility  Level  Operations —  * 

4c  ]|c  ]|c  ]|e  %  ]|c  ;|c  4c  4c  9|c  4c  4c  1 *******  t  ******  9fc  %  ic  9|c  4e  4c  )|c  3((  :4c  4c]lc  %  3|c  9|c  t 

Enter  To  select  the  desired  submenu  of  operations 

1.  Activity  Operations  Menu 

2.  Data  Element  Operations  Menu 

3.  Historical  Activity  Operations  Menu 

4.  Calls  Relation  Operations  Menu 

5.  ICOM  Relation  Operations  Menu 

6.  Consists^Of  Relation  Operations  Menu 

7  CLIPS  Operations  Menu 

8.  ICOM  Fact  Operations  Menu 

9.  Activity  Fact  Operations  Menu 

0.  EXIT 

SELECT  A  NUMBER:  7 

Enter  To  select  this  operation 
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1.  Assert  all  facts  into  the  CLIPS  Working  Memory. 

2.  Display  all  the  facts  in  CLIPS  Working  Memory. 

3.  Clear  the  CLIPS  Working  Memory. 

0.  EXIT 

SELECT  A  NUMBER:  1 

ICOM  facts  for  CLIPS  retrieved,  if  any< 

CLIPS  WM  -  a  set  of  facts  were  asserted. 

Project  name  fact  retrieved. 

CLIPS  WM  “  a  set  of  facts  were  asserted. 

Activity  facts  for  CLIPS  retrieved,  if  any. 

CLIPS  WM  -  a  set  of  facts  were  asserted. 

Data  element  facts  for  CLIPS  retrieved,  if  any. 

CLIPS  WM  -  a  set  of  facts  were  asserted. 

Historical  facts  for  CLIPS  retrieved,  if  any. 

CLIPS  WM  -  a  set  of  facts  were  asserted. 

Calls  relation  facts  for  CLIPS  retrieved,  if  any. 

CLIPS  WM  “  a  set  of  facts  were  asserted.. 

Consists  of  relation  facts  for  CLIPS  retrieved,  if  any. 
CLIPS  WM  -  a  set  of  facts  were  asserted. 

All  facts  for  CLIPS  retrieved. 

PRESS  ANY  KEY  -  THEN  RETURN  TO  CONTINUE:  1 


Enter  To  select  this  operation 

1.  Assert  all  facts  into  the  CLIPS  Working  Memory. 

2.  Display  all  the  facts  in  CLIPS  Working  Memory. 

3.  Clear  the  CLIPS  Working  Memory. 

0.  EXIT 

SELECT  A  NUMBER:  2 


;  Notice:  Each  fact  is  assigned  a  fact  number,  f-#. 

;  There  are  753  facts.  Only  one  set  of  facts  are  kept  here 
;  as  an  example. 

t^*****t*StdiTt  of  Working  Memory******** . 

f“l  (icom-tuple  Control^Elevator  summons_indication  cl) 

f-2  (icom-tuple  Control^Elevator  floor_sensor  c  2) 

f-3  (icom-tuple  Control_Elevator  door^sensor  c  3) 

f-4  (icom-tuple  Control_Elevator  system_control  c  4) 

f-5  (icom-tuple  Control^Elevator  control's ignals  o  5) 

f-6  (icom-tuple  Control_Elevator  passenger^requests  i  7) 

f-7  (icom-tuple  Control^Elevator  overload's ensor  i  8) 

f-8  (icom-tuple  Control_Elevator  floor .motor .drive  m  9) 

f-9  (icom-tuple  Control .Elevator  door.motor.drive  m  10.99999999) 

f-74  (icora-activity-inputs  Control.Elevator  2) 

f-75  (icora-activity-controls  Control.Elevator  4) 

f-76  (icom-activity-outputs  Control.Elevator  1) 
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1-77  (icom-activity-raechanisras  Control.Elevator  2) 


1-158  (project -name  Control.Elevator) 

1-159  (act-name  Control^Elevator) 

1-160  (act-numb  Control^Elevator  AO) 

1-161  (act-desc  Control.Elevator  not-null) 

1-162  (act-has-child  Control.Elevator  Store_Request) 

1-163  (act-has-child  Control.Elevator  Elevator^Control) 

1-164  (act-has-child  Control^Elevator  Schedule^Elevator) 

1-165  (act-rel-type  Control^Elevator  null) 

1-166  (act-rel  Control_Elevator  null) 

1-167  (act- vers ion  Control^Elevator  null) 

1-168  (act-ver-chg  Control.Elevator  null) 

1-169  (act-date  Control^Elevator  null) 

1-170  (act-author  Control^Elevator  null) 


1-384  (data-element-name  sumraons.indication) 

1-385  (data-element-type  summons.indication  null) 

1-386  (data-eleroent-roinimum  summons^indication  null) 

1-387  (data- element-maximum  summons^indication  null) 

1-388  (data-element-data-range  s\unmons_indication  null) 
1-389  (data-element-values  summons^  indicat  ion  null) 
1-390  (data-desc  summons^  indicat  ion  not-null) 

1-391  (data-rel  summons_indication  null) 

1-392  (data-r el-type  summons^indication  null) 

1-393  (data-ele-ver  summons^indication  null) 

1-394  (data-e-v-chg  siunmons_  indicat  ion  null) 

1-395  (data-ele-date  suramons.indication  null) 

1-396  (data-ele-author  summons^ indicat ion  null) 


1-748  (historical-tuple  Control_Elevator  AO) 

1-749  (calls-relat ion-tuple  Building.Transport  Building.Structure  All) 

1-750  (consists-ol-name  1  elevator^status  up/down) 

1-751  (consists-ol-name  2  elevator_status  stopped) 

1-752  (consists-ol-name  6  sequenced.signals  earl ier„ signals) 

1-753  (consists-ol-name  7  sequenced.signals  later^signals) 

ol  Working  Memory******** 

PRESS  ANY  KEY  -  THEN  RETURN  TO  CONTINUE:  1 


Enter  To  select  this  operation 

1.  Assert  all  lacts  into  the  CLIPS  Working  Memory. 

2.  Display  all  the  lacts  in  CLIPS  Working  Memory. 

3.  Clear  the  CLIPS  Working  Memory. 

0.  EXIT 

SELECT  A  NUMBER:  0 

PRESS  ANY  KEY  -  THEN  RETURN  TO  CONTINUE:  1 


D-4 


♦  ESSENTIAL  SUBSYSTEM  EDITING  AND  DEBUGGING  MENU  * 

♦  Warning;  These  operations  allow  you  to  directly  * 

♦  exercise  the  object  operations.  Use  extreme  care.^ 

♦  —Essential  Model  and  Utility  Level  Operations —  * 

I|t  4t  4c  41  %  4c  >|t4(  %  4c  :|c  *  I|t  4c  %  4t  1 %%  >|C  ]|c  %1|(  ^  4(  4t  t 

Enter  To  select  the  desired  submenu  of  operations 

1.  Activity  Operations  Menu 

2.  Data  Element  Operations  Menu 

3.  Historical  Activity  Operations  Menu 

4.  Calls  Relation  Operations  Menu 

5.  ICOM  Relation  Operations  Menu 

6.  Consists^Of  Relation  Operations  Menu 

7  CLIPS  Operations  Menu 

8.  ICOM  Fact  Operations  Menu 

9.  Activity  Fact  Operations  Menu 

0.  EXIT 

SELECT  A  NUMBER:  0 

PRESS  ANY  KEY  -  THEN  RETURN  TO  CONTINUE:  1 


4c  4c  ♦  4(  4c  4c  4t  4t  ♦  4c  ♦  4t  4(  4(  %  «  ♦  4c  ♦  4t  %  ♦  4(  ♦  ♦  *  *  ♦  ♦  4t  ♦  4t  4(  4c  4c  ♦  4c  ♦  *  ♦  4(  ♦  4t  4(  4(  4>  4(  ♦  4<  ♦  4(  ♦ 

*  THE  ESSENTIAL  SUBSYSTEM  4c 

♦  TEST  AND  DEMONSTRATION  MAIN  MENU  4c 

4'  —  SAtool  II  Level  Operations  —  4c 

4c  4c  4c  4c  4c  4c  4(  4c  4c  4c  4c  4c  4c  4c  4c  4c  4c  4c  4c  4c  4c  4c  4c  4c  4c  4c  4c  4c  4c  4c  4c  4(  4c  4c  4c  4c  4c  4c  4c  4c  4c  4‘ 4c  4c  4c  4c  4c  4c  4c  4c  4c  4(  4c 

Enter  To  select  the  desired  operation 

1.  Restore  (load)  a  project  from  disk 
(Warning:  all  current  data  cleared) 

2.  Save  the  current  project  to  disk 

3.  Display  the  current  project  name 

4.  Change  the  current  project  name 

5.  Create  and  display  a  data  dictionary  entry 

6.  Add  a  box/activity  to  the  project 

7.  Connect  2  boxes  with  a  data  element/arrow 

8.  Check  Syntax  of  current  project 

9.  —  Submenus  for  Low  Level  Operations  — 

0.  EXIT 

SELECT  A  NUMBER:  8 

ICOM  facts  for  CLIPS  retrieved,  if  any. 

CLIPS  WM  -  a  set  of  facts  were  asserted. 

Project  name  fact  retrieved. 

CLIPS  WM  -  a  set  of  facts  were  asserted. 

Activity  facts  for  CLIPS  retrieved,  if  any. 

CLIPS  WM  -  a  set  of  facts  were  asserted. 

Data  element  facts  for  CLIPS  retrieved,  if  any. 

CLIPS  WM  -  a  set  of  facts  were  asserted. 

Historical  facts  for  CLIPS  retrieved,  if  any. 

CLIPS  WM  "  a  set  of  facts  were  asserted. 

Calls  relation  facts  for  CLIPS  retrieved,  if  any. 
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CLIPS  WM  -  a  set  of  facts  were  asserted. 

Consists  of  relation  facts  for  CLIPS  retrieved,  if  any. 

CLIPS  WM  -  a  set  of  facts  were  asserted. 

♦♦♦♦  Essential  Subsystem  Syntax  Checking  Messages 

===>  The  project  ==  Control.Elevator  ==  is  checked  as  follows: 


ERRORS  are  related.  If  a  parent  activity  can^t  find 
a  boundary  arrow  in  its  child  activities  boundaries,  that 
means  its  child  activities  can*t  also  find  a  boundary  arrow 
from  its  parent  activity.  Two  ERRORS  will  be  raised 
for  both  the  pairent  and  child  activities.  Thus,  a  raidle 
level  data  error  will  raise  4  ERROR  messages.  Since  there 
axe  two  sets  of  parent  and  child  activities. 

A  set  of  saone  IDEFO  figures  as  described  in  chapter  II 
MARKED  with  DESIGNED  ERRORS  is  listed  below.  Inconsistent 
data  input  are  marked  with  a  no,  not  or  a  false 
preceeding  the  data  name. 


♦♦♦♦  Essential  Subsystem  Syntax  Checking  Messages 

===>  The  project  ==  Control^Elevator  ==  is  checked  as  follows: 

Waring:  activity  A2  has  more  than  6  child  diagrams. 

Notice:  Please  manually  check  to  make  sure  that  there  is  no 
such  an  warning  lower  that  4  levels  of  hierarchy. 

;  Activity  A27 

WARNING:  Activity  number  A265  Send^Signals  needs  a 
description. 

ERROR:  Activity  Check^Destination  needs  at  least  1  control. 

;  Activity  A21  should ^nt  have  two  input 

ERROR:  Data  inconsistency  between  parent  activity 
Sort^Signals  data  ‘o’  false^signals  and  its  child 
diagrams . 

;  Parent  A26  output 

ERROR:  Data  inconsistency  between  child  activity 
Send.Signals  data  ‘o*  signals  and  its 
parent . 

;  Child  A26  output 

ERROR:  Data  inconsistency  between  child  activity 
Comparers ignals  data  *c'  not^conf irmed  and  its 
parent . 
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Figure  D.l.  Hierarchy  Diagram  for  ^Control  Elevator’ 


Figure  D.2.  A-0  Essential  Model  Diagram  for  ‘Control  Elevator’ 
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Figure  D.3.  AO  Diagram  for  ‘Control  Elevator’ 
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AUTHOR:  Min-fuh  Shyong 


DATE:  2/26/91 


READER: 


PROJECT:  Control  Elevator 


REV:.  1.0 


DATE: 


NODE: 


A1 


TITLE:  Manage  Request 


NUMBER: 


Figure  D.4,  A1  Diagram  for  ‘Control  Elevator^ 
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Figure  D.5.  A12  Diagram  for  ‘Control  Elevator’ 
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Figure  D.6.  A2  Diagram  for  ‘Control  Elevator’ 
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TITLE:  Sort  Signals 


Figure  D.7.  A26  Diagram  for  ‘Control  Elevator^ 
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;  Child  A'^fl  control 


ERROR:  Data  inconsistency  between  child  activity 
Clear^Destination  data  *i*  no^stopped  and  its 
pairent . 

;  Child  of  A12,  A123  pipelined  input 

ERROR:  Data  inconsistency  between  parent  activity 
Elevator.Control  data  ‘o^  signals  and  its  child 
diagrams . 

;  Parent  A2  output  and  A26  output 

ERROR:  Data  inconsistency  between  parent  activity 

Elevator.Control  data  *c^  no_floor_sensor  and  its  child 
diagrams . 

;  Parent  A2 

ERROR:  icom  inconsistency  between  activity  Elevator^Control  and  its 

child  diagram  Checkjestination. 

;  Parent  A2  icom  inconsistent  with  its  child 

ERROR:  Data  inconsistency  between  child  activity 
Sort^Signals  data  *o*  false_ signals  and  its 
parent . 

;  A26  output  inconsistent  with  A2  output 

ERROR:  Data  inconsistency  between  child  activity 
Monitor^Arrival  data  *c^  floor^sensor  and  its 
parent . 

;  A22  control  inconsistent  with  A2 

ERROR:  Data  inconsistency  between  parent  activity 
Store_Request  data  *i’  passenger^requests  eind  its 

child  diagrams. 

;  A1  input  inconsistent  with  All 

ERROR:  Data  inconsistency  between  parent  activity 

Control^Elevator  data  *c*  floor^sensor  and  its  child 
diagrams . 

;  Parent  AO  control  -  A2 

ERROR:  Data  inconsistency  between  child  activity 

Elevator^Control  data  *c*  no^f loor^sensor  and  its 
parent . 

;  Child  A2  control  -  AO 


Since  there  are  ERRORS  occured,  so  the  icom  number 
between  each  pair  of  parent  and  child  activities  (no  matter 
at  what  level)  might  be  inconsistent.  But  it  might  because 
of  a  pipeline  data  element.  So  a  WARNING  will  be  fired 
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;  by  the  syntax  checking  expert  system. 


WARNING,  there  might  be  an  ERROR:  The  number  oi  boundary  controls 
of  the  parent  activity  Sort^Signals  is  1  control (s)  less 
than  its  child  boundary  controls. 

Are  there  ‘‘consists  ol**  data  items  at  boundary? 

Please  recheck  the  syntax. 

WARNING,  there  might  be  an  ERROR:  The  number  of  boundary  inputs 
of  the  parent  activity  Manage destination  is  1  input (s)  less 
them  its  child  boundary  inputs. 

Are  there  “consists  of“  data  items  at  boundary? 

Please  recheck  the  syntax. 

WARNING,  there  might  be  an  ERROR:  The  number  of  boundary  controls 
of  pairent  activity  Elevator_Control  is  1  control(s)  more  than 
its  child  activities. 

Are  there  ‘‘consists  of“  data  items  at  boundary? 

Please  recheck  the  syntax. 

WARNING,  there  might  be  an  ERROR:  The  number  of  boundary  inputs 
of  the  patrent  activity  Elevator^Control  is  1  input (s)  less 
than  its  child  boundary  inputs. 

Are  there  ‘‘consists  of“  data  items  at  boundary? 

Please  recheck  the  syntax. 

ERROR:  Data  inconsistency  between  parent  activity 

Mamage.Destination  data  ‘i^  elevator^status  aind  its  child 
diagrams . 

;  Parent  A12  pipeline  data  outout,  child  data  inconsistent 
Clips  run  completed.  Rules  fired  =  196 


PRESS  ANY  KEY  -  THEN  RETURN  TO  CONTINUE: 


;  NOTE:  If  no  errors  were  found;  only  a  few  ‘consists  of'  data 
;  elements  are  used  at  boundary.  Then  the  Syntax  Expert  System 
;  will  give  the  following  checking  results. 


****  Essential  Subsystem  Syntax  Checking  Messages 

===>  The  project  ==  Controldlevator  ==  is  checked  as  follows: 

WARNING,  there  might  be  an  ERROR:  The  number  of  boundary  inputs 
of  the  parent  activity  Manage_Destination  is  1  input (s)  less 
than  its  child  boundary  inputs. 

Are  there  ‘‘consists  of“  data  items  at  boundary? 

Please  recheck  the  syntax. 

CONGRATULATIONS:  No  syntax  errors  encountered. 

SUGGESTION:  Please  recheck  logical  structure  of  your  project 
for  perfection 
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Clips  run  completed.  Rules  fired  =  175 

PRESS  ANY  KEY  ~  THEN  RETURN  TO  CONTINUE:  1 


♦  THE  ESSENTIAL  SUBSYSTEM  ♦ 

*  TEST  AND  DEMONSTRATION  MAIN  MENU  * 

★  —  SAtool  II  Level  Operations  —  * 

Enter  To  select  the  desired  operation 

1.  Restore  (load)  a  project  from  disk 
(Warning:  all  current  data  cleared) 

2.  Save  the  current  project  to  disk 

3.  Display  the  current  project  name 

4.  Change  the  current  project  naone 

6.  Create  and  display  a  data  dictionary  entry 

6.  Add  a  box/activity  to  the  project 

7.  Connect  2  boxes  with  a  data  element/arrow 

8.  Check  Syntax  of  current  project 

9.  —  Submenus  for  Low  Level  Operations  — 

0.  EXIT 

SELECT  A  NUMBER:  0 

csh>  exit 

csh> 
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